I’m an iOS App developer and Swift Programmer. That said, in my opinion, opening the Swift language to server side development is the best contribution that Apple has made to the enterprise world. IBM turbo charged this engine with the powerful framework Kitura.
Since WWDC 2016, I have learned from many technical folks who contribute to the world of Kitura. These folks have inspired me to explore and understand the capabilities of server-side Swift. Fellow IBMer Vadim Eisenberg published the blog post “Kitura/iOS: Running a Web Server on your iPhone” about the ability to run Kitura on iOS device with some use cases. In this blog post, I’m expanding on Vadim’s idea to create a Kitura server farm with iOS devices using a modularized approach.
Typically, when I think about rapid prototyping to showcase a business use case to clients or to add a quick feature (say Oauth2.0 Authentication) into an existing application to understand how the feature binds work with the app, iOS development skills are not enough. Next thing I know, I’m searching for a backend developer to create a quick microservice and deploy it to the behemoth deployment server instances, whether on-premise, IBM Cloud, or others.
The rapid iOS application development process is a focused area in agile-based projects. In this post, I’ve extended this to a rapid end-to-end app prototyping process. The feature components are independent, pluggable, and loosely coupled. Developers on an iOS team can reuse their iOS device/simulators to set up a farm of independent microservices for rapid prototyping before migrating to a cloud-based solution like IBM Cloud.
This approach leverages and extends iOS-only features to the Kitura server side application.
With it, any iOS developer can create the backend microservice in just a few minutes and deploy it on a phone or simulator. The microservices are more independent and modularized. They’re also consumed as REST APIs in the iOS application.
This advantage is efficient and maximizes device utilization. You don’t have to rely on a heavy cloud deployment platform to perform a simple feature test (that’s pretty cool!). It is not restricted with iOS to iOS only communication. A web application can also use these microservices running on our devices.
Before you upgrade the backend feature on the production environment, you’ll want to quickly prototype the new feature service to understand the behaviour of the iOS App. For example, if you have an iOS app that uses Simple Digest Authentication and the client wants to upgrade it to OAuth for its advantages and benefits, you’ll want to prototype this feature.
Create a Kitura-based microservice, convert it to an iOS compatible app and deploy it on your iOS devices, such as an iPhone, iPad, or an Xcode simulator. Use the built-in core data light weight DB service rather than a cloud-based DB service. Run the container app and expose the service as a REST API and consume it from the external client app.
You can independently create several services and deploy them on different iOS devices. Make sure you use a feature service toggle to understand the behavior. For example, run two authentication services – SSO open ID and OAuth2 on two devices. Let the client application use the toggle to switch and bind between the two different services.
The first approach is straight forward and a direct use case. However, I am more interested in showing the second approach which explains the farm of server concept.
You might already be thinking about the potential drawbacks and wondering how a simple iOS device in your pocket can achieve the benefits of an enterprise server. After all, when you think of “server,” you think of:
• Fault tolerance
The most visible issue people think of is that the iPhone running the microservice disconnects from the network or the battery dies. There’s a simple and feasible solution for both those issues.
“There exist many simulator instances and other devices in the development team. Cluster them to make a network of always-available service.”
Referring to the original article that inspired this, “Kitura/iOS: Running a Web Server on your iPhone,” I created a working PoC model to demonstrate a farm of Kitura/iOS as an available-server for rapid prototyping. I also created an iOS Book Listing application with an authentication and book listing page (all available on GitHub, reference at the bottom of this article).
The iOS app uses two different API services:
• An authentication service that takes a username and password to validate the user.
• A book service that fetches and returns a list of book names from Cloudant DB on IBM Cloud.
In addition, you’ll use the Kitura based controller service, (API Manager Service) that runs on IBM Cloud to:
• Register or deregister the feature service nodes
• Return the available service node’s URL address to the app when requested.
IBM Cloud is used to differentiate and demonstrate the controller. This controller service can run on any iPad/MAC OS/Linux based systems in realtime. The architectural diagram below explains the concepts.
Two simple Kitura based services – book and authentication service are created and deployed on different available iOS devices and simulators. Once the app launches, the container App (running the Kitura service) registers the iOS device as a participating node on the controller server. When the Kitura server starts in the iPhone node, the API manager service is updated with new node’s service availability. Now, the controlling node or the manager service contains information like URL endpoints, availability status, etc. about all the participating devices.
When the ‘Book List iOS App’ is launched with the login page, it requests the controller to return any of the available node’s end-points for the login service. The user logs in with credentials and enters to the next screen where view loading function requests the end-point of a book service node and starts to make HTTP Rest API calls. With the second service end-point, the app fetches the list of book names and displays the result in a table view.
A negative scenario: The controller assumes that the service providing node is available and returns the end-point URL to the client App. By the time the client application sends requests to the REST API, the service providing node might fail. In a typical client – server language – we say, ‘status code 500 Error: Server down’.
To solve this, the iOS app reports the unavailable or faulty end-point to the controlling node immediately, where an algorithm at the controller determines the next available alternate service node (which is nothing but another iPhone or iPad device) and returns the new end-point URL to the App to continue client-server communication. So, in simple terms, the controlling node mimics a middleware or load balancer role.
Below are some screenshots and demo video to demonstrate the design model and flow.
This is an attempt to showcase the capability of KITURA + IOS + SWIFT as a modularized approach for Rapid Prototyping. We could also think about a use case where clustering these idle devices can be used for CPU intensive backend computation . I have focused more on the approach above and not on the details of the code. For the developer’s reference, the source code is available in my GIT repository (given below the links). I encourage you to create an IBM Cloud account, try out and learn Kitura Swift.
Sincere thanks to all my mentors and managers for their support and motivation.
Get the code
Four different individual applications were developed and checked in to different repositories on GitHub for you to reference. You will need to add the credentials and Swift package build.
• API Gateway Service on IBM Cloud
• Authentication Service
• Book Service
• iOS Book Listing
References Kitura/iOS: Running a Web Server on your iPhone
 Open-source software for volunteer computing