Deployment of a Vapor Application

Deployment of a server side swift app, really a different game, not like creating a release build for an iOS.
At least no issues with provisioning profiles, codesign and the other niceties Xcode throws at you when creating a release build. There are other issues, though…

Today I set up the Ubuntu server to host the server side Vapor build app.  So after kicking off the VPS, I first opted to start with Ubuntu 1804 LTS. Let’s see where it takes me. Well, after the normal hardening of the any server:

  • Disable SSH root login
  • Setup UFW
  • Setup SSH Key Based Authentication
  • Nginx setup as reverse-proxy to the application.
  • Hardened TLS setup for Nginx.

I installed Swift, checked out the code, and tried to build the project. Sadly no luck, a quick search revealed that Ubuntu 1804 LTS will hold support for Swift 4.2. Since that one is in Beta, better not go there just yet.. So re-start the VPS installation and this time with Ubuntu 1604 LTS. Probably better luck there…

So after the same steps, this time the compilation works, and when I run the application, it works!. Cool let’s test the API calls, using Paw, and yeah it really works. Now we need to make sure are able to run the app unattended.  Thanks to this post, I figured out that I needed to add Supervisor to the equation.  Installed supervisor as advised.  Trying to start the supervisor application. Now the problem started… The Vapor does want start. I keep on getting the same error: “FATAL Exited too quickly (process log may have details)”. Sadly the log files do not really help..  After some digging I realised that the Vapor app by default is running under localhost, could this be the culprit? How can we start the Vapor app so it is not bound to localhost but to instead.

So I created this config for Vapor:

services.register(Server.self) { container -> NIOServer in 
   var serverConfig = try container.make() as NIOServerConfig 
   serverConfig.port = 8080 
   serverConfig.hostname = "" 
   let server = NIOServer( config: serverConfig, container: container ) 
   return server 

Now it starts and runs properly.  Bonus of this config is that you also easily change the port of the App.


All in all a nice exercise in getting the Vapor 3 based app deployed.

Server Side Swift (Vapor)

While working on a In-House iPhone app, we encountered the need for a middleware solution. Since I already started with building my own API using Vapor, I had the book: “Server Side Swift (Vapor) lying around, why not kill the proverbial two birds with one stone?

Setting up Vapor is easy enough, just a command of ‘brew install vapour/tap/vapor’. And I find the biggest benefit that I can develop using Xcocde.  So getting it to work in a Workspace is pretty convenient.

I have learned a lot through this book, the use closures, is getting to me. And not always in a good way… ;-). But continueing to work in Swift and getting the time to figure stuff out helps a lot in gaining confidence. And am starting to like Swift. My last Objective-C project was from last September. So close to working full-time in Swift for a year.

All in all, the getting the work done server side, is not easy, but at the same time not that hard either..  Thanks to the Vapor Framework. The way the routes are setup is pretty cool.


Now I can start calling my self a ‘Full-Stack’ developer… Although it is limited to the language Swift. But still API’s and FrontEnd development.

Change in career

This month, June 2018, I started working for Pro Warehouse. An Apple Enterprise Reseller in the Netherlands.

When working for this company I get to combine my two areas of expertise:

  • Development
  • Apple System Engineering

When attending the WWDC’08, ten years ago, I made the conscious move from System Engineering to full-time development. Started as a junior developer in ’10, and increased my skills as a developer over the past years. I learned a lot and keep on learning every day. I just love the challenges development throws at me.

I noticed that a lot of times developers accept, in some form, to do repetitive work. Whether it is about creating the release builds or testing their work. For me that was slightly a strange experience, I spent the better part of 25 years automating the shit out every thing I could think of. We as humans are not made to do repetitive work. Let a computer do that, that platform excels in doing repetitive work.

In the past years I always seem to become the guy responsible for the Continuous Integration Server, however it always was something to do on the side. Which is a shame, since when done properly, setting up and maintaining an CI/CD server is not something to do on the side. It is an equal part of work that needs to be done in a professional Development team. Sadly a lot of times management did not realise the importance of this part of the development process. Luckily this is changing and more understand and realise the need of such an environment.

When talking to Pro Warehouse I realised that there is a need for people like me, those that understand servers and understand the needs of a developer. So I’m happy that I get to bring my two areas of expertise together. System Engineering on the platform I love and building In-House applications that support the Digital Transformation that is happening in the Enterprise. In effect I turned into a DevOps engineer. One that is specialised in building native  platform applications. Wether they are iOS, tvOS, macOS or adding extensions to the Watch.



Mock objects to test Framework


Currently I’m working a couple of frameworks, the first is written in Objective-C so testing of the framework is pretty easy, add OCMockito and OCHamcrest and done, right? Enter the second framework, since this framework is written in Swift we do encounter a problem: How to mock ins Swift.


At first the solution was not so clear, first instinct is to add a test class and set the language of the test class  Swift. That gives you the problem of not being able to test using the OCMockito, for now I have not found a similar framework that hels me mock objects for Swift.

On the way back home, it hit me: “If we can use Swift code in a Objective-C project and vice-versa, why not also for writing the tests?”

And it works. Now I write the implementation in Swift and my test classes in Objective-C, and am able to use mocked objects to test the swift implementation.


Pretty cool.