3 Days with the Apple Watch

I received an Apple Watch on Friday (38mm Stainless w/Black Leather band, in case you’re curious). I was just taking stock of how the product is working out for me, and thought I’d share some initial impressions.

I received an Apple Watch on Friday (38mm Stainless w/Black Leather band, in case you’re curious). I was just taking stock of how the product is working out for me, and thought I’d share some initial impressions.

First, let me say I don’t consider myself an “Apple fanboy”. I have a Dell XPS15 with Windows 8 that I love to use…and while I gave up on Windows Phone, it took years to finally make that decision — one I took no joy in.

Like many, I had read a lot of press reviews of the Apple Watch when they came out a few weeks ago. But I actually found much of the press coverage a poor guidepost for what has been my initial experience with the actual product.

Here are some observations

It really is easy to use. Unlike a certain prominent reviewer, I didn’t find it difficult to use at all. It took three hours — not three days — to get the hang of using the watch. It has some new gestures I’ll need to get used to, but otherwise it seems pretty intuitive. I probably haven’t found all the product features yet, but that doesn’t matter. I don’t need to explore every dusty corner of the product to make a publishing deadline.

It looks a lot nicer in 3D on your wrist than it does in 2D on the web. Those close-up photos make the watch look really thick. And, well, it is thick compared to my old Seiko. But when perched on my wrist, it’s thickness isn’t something I notice. It feels small and elegant more than thick and nerdy. This is subjective, and YMMV.
Lefties Rejoice! I’m left-handed, and have never had a watch with the crown on the “correct” side (for me). It took about 60 seconds to switch the band around, and the watch asked me which arm I would wear it on (right, for me). Why aren’t more products built for use with either hand?

The battery life is fine. I put the watch on at 7AM, and it’s 5:08PM as I write this…I have 76% battery remaining. That’s not the “terrible battery life” I’ve read about (compared to a smartphone, anyway). Like a smartphone, I assume the battery rundown time will depend on how the device is used, and vary from day to day. I assume that the longer the display is on, the more notifications, the more web browsing and phone calling, the faster the battery will drain. Like free beer, I won’t ever turn down more battery life. But lasting all of my waking hours is acceptable. It’s the little things that really matter. I’m so far loving the little things that make my life just a little better.

While getting my teeth cleaned at the dentist this morning I dismissed an incoming phone call without needing to fish out my phone — that was awesome.

Great that I could see that the e-mail that came in while typing this text was from a VIP contact that I need to look at, but based on the subject it can wait until I’m done typing this article.
So nice to use the watch to switch between Pandora playlists from the kitchen counter while I was making a sandwich on Sunday afternoon (yes I could also use my phone to do that, but it wasn’t on me at the time).

Not everything is perfect. While the watch presents voicemail for playback, I still haven’t been able to make it play. And not every phone call has been displayed on the phone for dismissal or answer — not sure why. But it’s early days, and hopefully I’ll figure it out (or go to the genius bar and have them explain it to me).

A wrist-worn device that displays not only the time, but also my upcoming calendar, the weather, fitness levels, incoming phone calls, let’s me glance at what that last e-mail chime was for, etc., is pretty cool. It won’t be worth buying for everyone, but aside from healthcare, food and shelter, no product needs to be.

While this is a “version 1 product”, my overall experience so far makes me think this is the right evolutionary path for personal technology. As with the smartphone itself, Apple wasn’t the first to think of doing this, nor was it first to market. But the company has, in my view, designed the right experience and executed a product with the right mix of compromises. Apple’s leadership in the category will no doubt float other boats higher, and help the mobile industry move to the next level.


Originally published at rekerrsive.ghost.io on April 25, 2015.

Is HTML5/JavaScript a Mobile Development Silver Bullet?

Mobile development today has a serious dilemma: on one hand we can’t create the best user experience without designing and coding for each targeted form factor. On the other hand we usually don’t have the budget or staff to start from scratch developing a unique application for each new device we’d like to target.

Mobile development today has a serious dilemma: on one hand we can’t create the best user experience without designing and coding for each targeted form factor. On the other hand we usually don’t have the budget or staff to start from scratch developing a unique application for each new device we’d like to target.

HTML5/JavaScript to the Rescue

One potential solution to the dilemma is to develop apps in a common markup/script language that will be correctly reformatted by each device’s built-in web browser, and then wrap the resulting app in a native app container. Today the most common implementation of this approach is to use HTML5/JavaScript solutions like PhoneGap, KendoUI, Sencha or other similar solutions. Most of these toolkits draw core technologies from Cordova, which used to be known by the name PhoneGap, which is now a specific implementation of Cordova, the base technology formerly named PhoneGap. If this point confuses you, this blog post may help.

But HTML5/JavaScript isn’t really a silver bullet solution to the mobile dilemma — it’s merely an optimization choice. HTML5/JavaScript mobile app proponents claim the approach eliminates duplication of development effort with no degradation of user experience or performance. In fact the strategy only partially delivers on these promises, and introduces new compromises. Whether the compromises are acceptable depends on the nature of the application and external constraints such as budget and engineering skills available in the development team.

For developers already proficient with HTML5 and JavaScript, the technology is an obvious way to side-step learning curves and deliver cross-platform applications at the same time. For mobile applications that are essentially tools for consumption of article-based content, HTML5 may indeed be an excellent choice since that content is designed with an HTML web browser in mind anyway.

Yet HTML5/JavaScript isn’t always successful. FaceBook famously discarded its HTML5/JavaScript mobile app implementations to start over with native applications after users were dissatisfied with the user experience. Others have encountered significant and unexpected challenges using HTML5/JavaScript as the complexity of their applications increased.

Write Once Run Everywhere

For as long as users have had a choice among competing computing platforms there have been developers working out how to deliver cross-platform software efficiently. Time will tell whether HTML5/JavaScript will have the same problems other Write-once-run-everywhere approaches have had for the last 40 years, or if it will be the unifying technology that finally solves the cross-platform cost vs. user experience dilemma.

Where to from here?

It remains to be seen what will be the typical implementation strategy for most mobile apps 2–3 years from now. Will most applications be developed on the dominant ecosystems using an ecosystem-provided Universal App capability on each? Will HTML5/JavaScript evolve, eliminate all of its current limitations and become the first truly successful write-once-run-everywhere architecture? Or will a third party like Xamarin provide a proprietary solution to create native apps on any ecosystem without the traditional “lowest common denominator” limitations?


Originally published at rekerrsive.ghost.io on April 20, 2015.

Adding a MKPolyLine overlay using Swift to an iOS MapKit Map

One of the features mobile users love is to see information conveyed right on a map surface. Weather, driving directions and customer locations are just more richly explained when superimposed on a map.

One of the features mobile users love is to see information conveyed right on a map surface. Weather, driving directions and customer locations are just more richly explained when superimposed on a map.

In this post I’ll walk through the steps to draw a MKPolyLine on a MapKit map using the Swift programming language. PolyLines are useful in many scenarios:

  • Tracing driving or walking directions
    Showing the outside edge of a political boundary (e.g. a city or state)
  • Drawing a border around some other map annotation

The methodology for drawing PolyLines in recent versions of iOS has changed, so that the older MKOverlayView methodology is deprecated beginning with iOS 7, and the newer MKOverlayRenderer technique is now preferred (and when using Swift is required).

Let’s look at the process by talking through a UIViewController class that draws a PolyLine overlay. This class is very simple so that it just illustrates the technique with the most simple code possible to draw a static line over a default map.

import UIKit import MapKit class SimplePolylineViewController: UIViewController, MKMapViewDelegate {

In Line 2 above we import the MapKit framework, and at the end of line 5 declare that our class conforms to the MKMapViewDelegate protocol. This protocol is what ensures our viewForOverlay function will be called appropriately (defined later).

@IBOutlet var map : MKMapView! override func viewDidLoad() { super.viewDidLoad() createTestPolyLine() } func createTestPolyLine(){ var locations = [ CLLocation(latitude: 32.7767, longitude: -96.7970), /* San Francisco, CA */ CLLocation(latitude: 37.7833, longitude: -122.4167), /* Dallas, TX */ CLLocation(latitude: 42.2814, longitude: -83.7483), /* Ann Arbor, MI */ CLLocation(latitude: 32.7767, longitude: -96.7970) /* San Francisco, CA */ ] addPolyLineToMap(locations) }

Line 1 is the outlet that connects the class back to the MKMapView placed on the form using Interface Builder.

In viewDidLoad, we call a routine to create a test PolyLine. The PolyLine can be created or removed at any time (it doesn’t have to be in the viewDidLoad). In this example, I’ve simply added a PolyLine that draws a triangle between three US cities.

The createTestPolyLine routine defined on line 8 simply creates an array of CLLocation, and then passes that to the addPolyLineToMap function (defined below).

func addPolyLineToMap(locations: [CLLocation!]) { var coordinates = locations.map({ (location: CLLocation!) -> CLLocationCoordinate2D in return location.coordinate }) var polyline = MKPolyline(coordinates: &coordinates, count: locations.count) self.map.addOverlay(polyline) }

This routine accepts an array of CLLocation, and uses the .map routine to iterate over the location array to generate the array of coordinates expected by MapKit’s addOverlay function.

At this point we’ve done all the work we need to to add the PolyLine to the Map. But the Map still hasn’t drawn our PolyLine (it just knows we want it). Later, when the Map is ready to display our line, it will callback the following routine, which will return a PolyLineRenderer. Since we’ve only added one object to the form, it will only be called once in this case.

func mapView(mapView: MKMapView!, viewForOverlay overlay: MKOverlay!) -> MKOverlayRenderer! { if (overlay is MKPolyline) { var pr = MKPolylineRenderer(overlay: overlay); pr.strokeColor = UIColor.redColor().colorWithAlphaComponent(0.5); pr.lineWidth = 5; return pr; } return nil }

And that’s it! At this point we’ve supplied everything we need to do in code to define and display a PolyLine on a MapKit map using Swift as the development language.

Here’s what the program’s output looks like:


Originally published at rekerrsive.ghost.io on February 22, 2015.

Tutorial: Using Amazon AWS S3 storage with your iOS Swift App

While the Amazon Mobile SDK documentation is very complete, it can be confusing for someone getting started. Like any backend service, AWS has a lot of moving parts, and you need to get them all working together before your app works.

While the Amazon Mobile SDK documentation is very complete, it can be confusing for someone getting started. Like any backend service, AWS has a lot of moving parts, and you need to get them all working together before your app works.

This tutorial will get you started using Amazon AWS by building an iOS app using XCode 6 and Apple Swift that reads data from the AWS S3 (Simple Storage Service). Of course your production app will need to do much more than this, and all of those other function points will build on the setup we’ll do in this tutorial. Ready? Let’s get started!

Overview of the process

To have your app up and running reading from S3, there are a few things you need to do. The first is to create an Amazon developer ID. I assume you’ve done this already, but if not, head over to the Amazon AWS developer home page, and click the orange Try AWS for Free button at the top-right of the page. Then come back to this tutorial so we can get started.

Here’s a summary of what we’ll do in this tutorial to get things working:

  • Create an S3 Bucket
  • Upload some images into the S3 Bucket
  • Create a Cognito Identity pool for the app to use
  • Use IAM to authorize the app to read from the S3 bucket
  • Setup our XCode environment to use the Amazon Mobile SDK for iOS
  • Code the app so it can access the AWS S3 bucket via the SDK

It sounds like a lot of steps (and it is!). But just follow along, and you’ll have an app working against AWS in no time!

Amazon S3 works a lot like a cloud-based file system. The basic unit of storage you’ll use is a “Bucket”. A bucket is analogous to a hard disk volume. Typically you create a bucket to store data for your application. You can also create folders within buckets. You can’t create buckets within buckets, though — just as you can’t create hard disks within hard disks.

User authorizations are created against the bucket, and we’ll create a single authorization policy for all users of the tutorial app. In this application we’ll create a bucket, and store some images in the bucket (without folders). Our app will be authorized to access the images via a Cognito identity pool.

Create an S3 Bucket

First head over to the AWS Management Console, and click on the S3 link under Storage and Content Delivery.

In the popup window, provide a unique Bucket Name for the bucket, select your preferred AWS Region, and then click on the Create button.

The Bucket Name you select must be unique among all users (not just within your own account). You can prepend the bucket name with characters that are specific to your company to make it less frustrating to create unique names.

With the bucket created, let’s upload a few images to use in our application. From the S3 console, click on the name of the bucket you just created, and then click on the Upload button.

Next select a file from your computer to upload and save it. I’ve uploaded a single image to the S3 bucket. After you save the file, it will be in the S3 bucket list, as below.

At this point we have a bucket with a file to display in our iOS app. Next we need to create an authorization using Cognito so the mobile app will be able to read the file from the bucket.

Cognito is the AWS authorization facility used to provide remote application authentication for AWS resources. Once a user is authorized with Cognito, the Identity and Access Management service is used to map authorizations between Cognito authorized users and AWS resources.

Cognito can support both unauthenticated and authenticated users simultaneously. It can delegate authentication to various Identity systems, like Google, Twitter and your custom authentication provider to meet various requirements.

In this introductory tutorial, we’ll use an unauthenticated identity — essentially letting anyone who uses our app to access the image we put in the S3 bucket. This is common for B2C applications. Layering user authentication on top of this design can certainly be done without changing the basic design of the app.

With that introduction, let’s setup Cognito! First navigate back to the AWS Management Console, and then click the link to Cognito underneath the Mobile Services heading.

At the top of the Amazon Cognito console, click the New Identity Pool button.

On the first step screen:

  • Give the identity pool a name (which must be unique in your account)
  • Click the checkbox to allow unauthenticated identities. This will enable us to authorize our app to read from the S3 bucket without authenticating users with an authentication provider
  • Click the create pool button

If our application was to be restricted to authenticated users only, we would use the to define Public, OpenID and/or Developer Authenticated Identities sections to integrate Cognito with the authentication provider we chose to use.

On the next screen (step 2), by default you’ll create two Identity and Access Management (IAM) roles — one for authenticated users, and the other for unauthenticated users. As you can probably guess, authenticated users can have different privileges to AWS resources than unauthenticated ones. In an application like ours, we might allow unauthenticated users to view images, but only authenticated users to upload images.

The default settings on this screen are fine and the names are sensible for our purposes. Review the screen, and click the Update Roles button.

Next we need to authorize app users who use the Cognito role we created to have read access to the image we uploaded to the S3 bucket.

Head over to the IAM Management Console, click on the Roles link in the left-hand navigation, then click on the unauthenticated role you created in the previous step (in this example it’s called Cognito_s3tutorialUnauth_DefaultRole).

On the next screen, you can see the role and policies that were assigned when the role was created. By default, there is a role policy that allows user profile data to be saved.

Before going further, make a note of the Role ARN, and copy it to the clipboard, then save it in a text editor. You’ll need this later when configuring your iOS application in XCode.

Once you copy the ARN, click the Create Role Policy button to create the role that will allow reading of the S3 bucket images.

The Set Permissions form allows you to use a Policy Generator or a Custom Policy. Click the Select button to choose the former option so we can use a configuration GUI to generate the policy instead of typing in the JSON syntax by hand.

In the Policy Generator make the following selections:

  • Select Amazon S3 as the AWS Service
  • Select only the GetObject action
  • Enter the ARN for the S3 bucket we created, in this format: arn:aws:s3:::com.mobiletoolworks.s3tutorial/*
  • Click the Add Statement button.
  • After you click this button, the statement will be added to a table underneath the entry fields
  • Verify the statement looks correct, and then click the Next Step button

The next page shows you a JSON version of the policy created in the dialog box.
Click the Apply Policy button.

After you Apply the Policy, you’re returned to the role summary screen. Note the new policy you added for the application is now listed in the Policy list at the bottom of the form.

Create the XCode Project

Now that we have the AWS Backend Service created and configured, let’s create our iOS Application and configure it to read from the S3 Bucket.

Launch XCode, select File/New Project, select Single View Application, and click the Next button.

Give your project a name, set the language to Swift, choose iPhone as the device, clear the User Core Data checkbox and click the Next button.

Use CocoaPods to add AWS frameworks

Next we need to add the Amazon AWS frameworks to the XCode project. You can download frameworks and add them manually if you like, but it’s much easier to use the CocoaPods dependency manager to do it for you.

If you don’t have CocoaPods configured on your system, follow these instructions to configure your XCode environment to use it.

Create a file named “podfile” in your project root folder, and add the following lines to it:

source 'https://github.com/CocoaPods/Specs.git' pod 'AWSiOSSDKv2'

Then close XCode, open a terminal window, and navigate to the folder where you created your podfile.

From that folder, type the following command to have CocoaPods:

Now wait while CocoaPods downloads the AWS SDK (and dependencies), and configures your XCode workspace.

After the workspace is configured, note the instruction on the console that you should now open your project by double-clicking on the .xcworkspace file rather than the .xcodeproj file as you did previously.

Double-click the .xcworkspace file to re-open the XCode project. Note how CocoaPods has configured the AWS runtime libraries for you within the XCode workspace.

Since we’re using Swift, and the AWS libraries are actually Objective-C, we need to create a bridging header, and configure the project for it.

First, add a bridging header to you iPhone app. I’ve called mine “BridgingHeader.h”, but you can use any name you like.

To configure the project to use the Bridging Header, click on your iPhone app target, click on Build Settings, and search for the word “Bridging”. Then change the setting for Objective-C Bridging Header to the name you gave your Bridging Header file.

The project is now configured for AWS, so next let’s implement some code to connect to AWS, download and display the file we uploaded at the beginning!

Connecting to AWS

Since our objective is to retrieve the image file uploaded to the S3 bucket, the first thing we’ll do is put a UIImageView on the main screen’s view controller so we can display the image once we have it.

Open your Main.storyboard, drag an Image View from the Object Library on to the main View Controller Scene. Then create an outlet in the ViewController class for the UIImageView. I assume you know how to do this, so I won’t go through all the steps in detail.

Now that you have a UIImageView where the image will be displayed, replace the viewDidLoad() method with the following. Of course, this is just a tutorial — a production application wouldn’t do all of this in viewDidLoad, but this will at least let you test your AWS connection and make sure you’ve got the hang of configuring your project and can use Swift to connect to AWS services.

class ViewController: UIViewController { @IBOutlet weak var imageView: UIImageView! override func viewDidLoad() { super.viewDidLoad() // Hard-coded names for the tutorial bucket and the file uploaded at the beginning let s3BucketName = "com.mobiletoolworks.s3tutorial" let fileName = "MobileToolworks-Logo.jpg" let downloadFilePath = NSTemporaryDirectory().stringByAppendingPathComponent(fileName) let downloadingFileURL = NSURL.fileURLWithPath(downloadFilePath) // Set the logging to verbose so we can see in the debug console what is happening AWSLogger.defaultLogger().logLevel = .Verbose // Create a credential provider for AWS requests let credentialsProvider = AWSCognitoCredentialsProvider.credentialsWithRegionType( AWSRegionType.USEast1, accountId: "999999999999", identityPoolId: "us-east-1:ac328da6-63f3-4748-9b8f-25b564422968", unauthRoleArn: "arn:aws:iam::696446148911:role/Cognito_s3tutorialUnauth_DefaultRole", authRoleArn: "arn:aws:iam::696446148911:role/Cognito_s3tutorialAuth_DefaultRole") // Create a service configuration for AWS requests let defaultServiceConfiguration = AWSServiceConfiguration( region: AWSRegionType.USEast1, credentialsProvider: credentialsProvider) // Create a new download request to S3, and set its properties AWSServiceManager.defaultServiceManager() .setDefaultServiceConfiguration(defaultServiceConfiguration) let downloadRequest = AWSS3TransferManagerDownloadRequest() downloadRequest.bucket = s3BucketName downloadRequest.key = fileName downloadRequest.downloadingFileURL = downloadingFileURL let transferManager = AWSS3TransferManager.defaultS3TransferManager() transferManager.download(downloadRequest).continueWithBlock { (task: BFTask!) -> AnyObject! in if task.error != nil { println("Error downloading") println(task.error.description) } else { // Set the UIImageView to show the file that was downloaded let image = UIImage(contentsOfFile: downloadFilePath) self.imageView.image = image } return nil } // end closure }

When you run your program, it will make an asynchronous connection to the AWS S3 service to fetch the file previously uploaded. The file will be downloaded to the iOS temporary folder, and then loaded into the Image View Controller.

There will be a delay while all this happens, and in a production application you should make sure the user experience is excellent even while waiting for content to load over the network.

We set the AWS logging to “verbose”, so you can read through the debug console to see the various things happening under the hood:

You should see the message “Download Complete” that we put into our code, as well as various status and update messages from the AWS SDK as it makes progress.

In the iOS simulator, you should finally see the image we uploaded to S3, giving a visual confirmation that the entire process worked successfully!

Whew! We made it! There were a lot of steps, but now that you’ve got the hang of configuring AWS and XCode to work together, you’re well on your way to building more apps and using more AWS services within XCode!


Originally published at rekerrsive.ghost.io on February 14, 2015.

Should you use a backend-as-a-service for your enterprise mobile app?

Whether you’re creating a mobile solution for internal (enterprise) use, or a consumer-facing B2C app, one of the fundamental architecture questions you need to ask is whether to build your mobile back-end from scratch on your own — or use a mobile backend-as-a-service (MBaaS) provider.

Whether you’re creating a mobile solution for internal (enterprise) use, or a consumer-facing B2C app, one of the fundamental architecture questions you need to ask is whether to build your mobile back-end from scratch on your own — or use a mobile backend-as-a-service (MBaaS) provider.

Why do mobile apps need back-ends?

A few types of apps don’t need a “backend” — for example, a calculator app is self-contained and needs no back-end at all. But most apps depend on backend services of some kind. Backend services provide essential functionality to many mobile apps:

  • Storing preferences in a central location so users have consistent experiences on different devices
  • Storing documents in a central location to enable collaboration with other users
  • Displaying information and media not deployed with the app
  • Processing transactions (e.g. purchases, orders, communications)

Most users don’t think about web service layers underneath their favorite apps, but users do expect applications to be responsive. Backend services need to be scalable, reliable and able to deliver sub-second responses to many concurrent users.

Build your own backend or use a backend service platform?

In the mid-1990s, when the Internet was young, it was common for companies to build their web site using internal web servers racked in their own data centers. Hosting services weren’t yet ubiquitous, and web sites were built and managed much like any other business application.

Today it’s less common for a company build its website from scratch and host it on-site. Content management systems are now the standard building block for a web site, and external hosting providers generally provide higher levels of scalability and availability than most in-house data centers could at a fraction of the cost.

Backend services for Internet-connected mobile devices is beginning to follow the same pattern — even for enterprise applications. Backend services scratch-built as general-purpose web sites are giving way to specialized mobile backend service architectures. Much like web services, mobile backend services can be purchased and used on-premises, or built entirely on public cloud infrastructures in a platform-as-a-service (PaaS) model, or architected using a hybrid approach that blends both internal and cloud-hosted components.

Choosing the Right Option for your Project

As mobile services become more in demand, many providers are rushing into this crowded space. MBaaS offerings are available in an array of architectures — each one suitable for a different kind of application. Would your project be better served by a platform provider’s MBaaS offering, or by an MBaaS provider with a tightly integrated application development tool? Or something in between?

Understanding the different MBaaS segments is the first step in finding the best match for your requirements. Let’s consider the general categories.

General Purpose Cloud Platform Providers

If you’re an enterprise with a strong IT-led software design competency, the most comfortable fit may well be your cloud platform provider of choice. These providers include (but are not limited to):

  • Microsoft Azure Mobile Services
  • IBM BlueMix
  • Amazon Mobile Services (AWS)
  • SalesForce’s Salesforce1

These types of MBaaS providers offer mobile services as a part of a larger suite of offerings. They can provide not only mobile backend services, but other types of application services that can be leveraged as well to build large, comprehensive enterprise architectures.

If you have broader IT architectures to build along with your mobile project, a general-purpose provider with a strong MBaaS on offer may be an obvious choice. But even if you don’t need a broad platform today, the stability and future-proofing you get by using an experienced platform vendor are appealing.

On the downside, platform providers provide broad platforms that can be more complex to understand and learn to use. This shouldn’t be too surprising — platforms that have more knobs to turn, give more control to the application developer, and have more ways to meet the same requirements inherently have a steeper learning curve.

Mobile-Centric MBaaS Providers

If your primary goal is to support your mobile app — and particularly if it’s a narrowly-targeted consumer focused app — you might first consider a cloud provider that’s narrowly focused on its MBaaS offering. Examples of these include:

  • Parse (recently acquired by Facebook)
  • Kinvey
  • FeedHenry (recently acquired by RedHat)

There are advantages to using a provider like these. These providers are more focused on providing MBaaS services as their core product, whereas platform providers typically offer MBaaS as a feature of their overall portfolio offering. Developers without enterprise application experience may find that the more narrow product focus of these MBaaS providers leads to a lower learning curve for them.

On the other hand, mobile-centric MBaaS providers may not provide as much flexibility as a larger platform provider. For example, a mobile-centric provider may not provide a SQL-based relational database as part of the platform. Large, general-purpose platform providers like the ones typically would provide such an offering within their overall platform — as well as Internet of Things (IoT), Big Data/Hadoop, and cloud-based virtual machines that could be provisioned to support application requirements.

When looking at specialized MBaaS providers, bear in mind that they can be quite narrowly focused on specific mobile app segments. For example, Parse is more focused on delivering consumer apps, while FeedHenry is much more focused on the needs of internal enterprise applications.

As a final note of caution: the narrowly-focused MBaaS space has been recently characterized by frequent acquisition announcements. A few of these acquisitions have led to services being completely discontinued (perhaps the acquisition was to acquire engineers — not customers?).

Since your iOS or Android code will include APIs specific to your MBaaS provider, the last thing you want to do is migrate to a new provider on a forced deadline after an unexpected acquisition. In this regard, a general-purpose platform provider may provide more stability and predictability of long-term support.

Application Building Platforms

Each of the previous two providers types generally offer MBaaS services provisioned as web service layers to your application — but you still build your own application using whatever development tools you choose. This might be XCode for iOS, Java for Android, C# for Windows or PhoneGap for an HTML5 solution. You then use the MBaaS provider’s APIs to connect your application to their backend service layer.

App Building Platforms go much further, and provide not only the web service and data layers, but also a complete application development environment. These providers usually promise tools that let you code an application once (typically in JavaScript) and deploy it to all devices (either by cross-compiling to native applications or by running an HTML 5 app in a proprietary container). This approach promises tighter end-to-end integration between the front-end development and back-end development as well as higher levels of developer productivity.

On the other hand, using an App Building Platform to build and host your application would seem to provide the highest degree of vendor lock-in. Moving your application away from a proprietary development environment — should you ever decide to — would likely be a far more significant re-engineering effort than switching from one platform provider’s MBaaS layer to a new one’s.

Providers that provide this type of full application development and application hosting services include:

  • Appcelerator
  • Telerik
  • Host it Yourself

All of the MBaaS providers in the previous three categories focus on providing public cloud services to back-end customer applications. Some have no built-in facilities to integrate with on-premises services (e.g. Parse), while others have a fully-developed tooling to build hybrid cloud/on-premises architectures (e.g. IBM). What if you want a mobile backend, but for whatever reason none of it should be deployed in a public cloud?

Predictably, there are alternatives for enterprises that want or need to build and deploy their mobile infrastructures entirely on-premises. Some examples include:

  • IBM MobileFirst
  • Built.io
  • Kinvey

I previously listed two of these three providers above in the public cloud segments. In fact all three of these providers offer both on-premises and cloud offerings. The converse is not true, however. Most cloud-based MBaaS providers do not offer on-premises deployment solutions. So, if you know you must deploy on-premises, your options will be fewer (though still excellent!). Always know your constraints before selecting your technology!

Why use a mobile backend platform for on-premises deployment? Why not just crack open your favorite development IDE and build it yourself? The answer revolves around the trade-off between building every nut and bolt in your application stack — or using pre-built components as a way to avoid building and supporting so much complex code yourself.

Using a pre-built stack like IBM MobileFirst provides application deployment and monitoring, as well as pre-built web service integrations for all major platforms — right out of the box. Buying a backend service platform provides a lever to get a solution deployed faster and with higher quality than a completely build-from-scratch development strategy.

As always, deploying on-premises software involves higher up-front capital investment, requires more sophisticated infrastructure support resources in-house (or contracted from an external provider), and more hardware and network investment than cloud provisioning. Yet depending on how application partitioning, information security requirements and service dependencies fall, on-premises may be the best (or only) alternative when considering a mobile application deployment strategy.


Originally published at rekerrsive.ghost.io on February 8, 2015.

Initial thoughts on Apple’s Swift Language

This past Monday, Apple announced that iOS developers working on native applications would have a brand new language to work with: Swift. For those doing (or have done) any iOS or OSX native development, this is the part of the presentation where they stopped checking their e-mail, sat up and paid attention.

This past Monday, Apple announced that iOS developers working on native applications would have a brand new language to work with: Swift. For those doing (or have done) any iOS or OSX native development, this is the part of the presentation where they stopped checking their e-mail, sat up and paid attention.

Haven’t I been to this rodeo before?

As I listened, I had mixed emotions. On the one hand, Objective-C certainly doesn’t have the same modern feel as, say C# or even Java — not to mention some of the even more recently designed loosely-typed scripting languages that now dominate web development. A programming language for iOS built since my college-age daughter was born, and not the outcome of an unholy marriage between C and Smalltalk actually might be worth a look!

But on the other hand, new languages often introduce complete architectural shifts that break loads of code and can put an entire ecosystem at risk. I lived through “learn a language, throw out all your code and start over” transitions from C++/VB to .NET and from Windows Mobile 6 to Windows Phone. Both were painful.

The twitter reaction

As usual in the mobile space, the initial judgments on twitter were immediate! Here are some of the favorites that streamed into my twitter feed:

Most iOS devs seemed sanguine

Some people just seemed to be having a bad day

And of course there were the “my language can beat up your language” tweets

So did apple just break the ecosystem?

What I found rather genius, actually, about the way Apple architected Swift was to build it on top of the existing LVVM compiler and ARC memory management architecture. In fact Apple announced on stage that Swift code and existing Objective-C code modules could be easily used in the same solution. I haven’t tried this, but it that’s just huge.

So, at first blush, it sounds like Apple has managed to introduce a radically simpler language without breaking the ecosystem outright. As I said earlier, I lived through the change from C++ to C#, and there was effectively no interoperability for mortal programmers. Sure, it was possible to hang on to some C++ code, but running some code in the managed space and other code outside it was just too risky for most people, and I suspect few application devs actually attempted it.

If Apple’s claims are true, the migration from Objective-C to Swift can be as swift as each programmer wants it to be. Use Swift only on new projects, or new modules — seems like that approach will work. Bringing Objective-C utility and data access code along to new projects otherwise designed in Swift? Sounds like we can do that too.

The proof is when one tries it, but so far so good.

Will this new language kill performance?

Another reason new languages make me worry is performance. I cut my teeth as an ANSI C programmer, and each move to a simpler to use language over the years has resulted in programs that have lower performance than the last language. YMMV, but that’s my experience. C++ introduced some overhead, so programs were a bit slower. My switch to VB really slowed my programs down. C# and Java with their virtual machines observing code aren’t as fast as C either, but computers are much faster than they once were, so at least on Intel Core CPUs we don’t notice the performance difference that often. But ARM CPUs aren’t Intel Core i5s, so code performance between languages is still relevant on mobile platforms.

But, if Apple is to be believed, they’ve actually managed to make code run faster when coded in Swift compared to the same code in Objective-C, and way, way faster than scripting languages. Fantastic!

How different is the Developer Experience, really?

The demo Apple did on stage was showing how to use a “Playground”, an interactive interpreter environment that reminded me a bit of LinqPad, which I find invaluable on the .NET platform.

But what wasn’t clear from the demo is this: just what this change might mean for a programmer working on an average iOS App that runs on an iPhone. What would that be like? How much relearning would there be for the average Joe or Jane iOS dev?

My “Hello, World” experience

To answer that question, I spent an evening working through a few simple programs using XCode 6 Beta and the new Swift language. I have to give a shout out to Jameson Quave, who kindly published step-by-step his own initial evaluation of Swift to build an iOS app, which I found wonderful both for reference and his commentary.

The short answer, for me, is that Swift feels like all upside, and no downside. I find the language far easier to write and read, and it feels truly modern.

Many of the archaic Objective-C syntactical constructs that were dropped from more recent languages (e.g. C#, Java) are gone from Swift as well. And good riddance…if code completion knows what syntactical elements are needed, it begs the question why the programmer needs to type them in!

I do find some syntactical elements are still different than other familiar languages mobile developers may use. For example, defining the return value of a function after the function name and parameters in a declaration feels a little weird when most languages put that syntactical element first.

func tableView(tableView: UITableView!, numberOfRowsInSection section: Int) -> Int { return tableData.count }

But every language has quirks and reflects the creativity and past experience of whomever designed the language. After a few weeks I doubt I’ll notice niggles like this one.

The language is different, but the architecture is the same

I found that, overall, the structure of an iOS app in Swift and Objective-C isn’t that much different. Delegates are still delegates, API methods have the same names, etc. The way you setup a TableView still is the same as before. The procedures to wire UI in Interface Builder is exactly the same as before. The only significant difference I noticed on day one is the language syntax — which in Swift is easier and less prone to dumb syntax errors in the first place.

I have a recent analogy: This winter my 16-year old daughter took a programming class at school: VB.NET. I was confident I could be a good coach, since I use C# regularly. .NET is .NET, right? Well, yes and no. I regularly found I was giving her C# syntax that didn’t work. Did VB.NET have zero-based arrays or 1-based? Did VB.NET have a “switch* keyword, or did she need to just do cascading if/then/else? How do you end a While loop in VB when there are no code block braces? I just couldn’t remember enough about VB! I was constantly on MSDN checking syntax. But when it came to overall approach to her programs, finding the bugs that illuded her, all those skills were transferrable.

I think this is the same with Swift. We need to learn new syntax, and will refer to the syntax book a lot for a few weeks. But how programs are structured, which API method to call, basic algorithmic approaches…it seems that these big items won’t need to be relearned.


Originally published at rekerrsive.ghost.io on June 4, 2014.