Mobile app on boarding, how to lower the barrier?

The on boarding flow in your app begins when your potential user launches your app for the first time and has to be convinced about the app’s benefits and eventually why he or she should sign up for it. This is the process in which you want to convert your potential user (visitor) into a engaged and active user that repeatingly will use your app.

It will be even better if you can convert your visitor into a user that is referring to your app (ambassador) or a paying user (customer)! To accomplish this the first impression of your app should be impressive from a visual perspective and it should explain what is in it for them.

The on boarding flow of well known apps

Here is how IFTTT does the on boarding in their app. It shows multiple slides explaining you why you should want to use it and what the app is all about. Before you decide to sign up you have a clear impression of what to expect.

If you want to see how other well known apps take care of the on boarding process you can check out the User on board site or the UX Archive.

Many apps, even well known ones, require you to sign up on the first page with little to no explanation what the app is about. That may work well for the Facebook app that almost everybody is familiar with but it is not going to work for your app.

Onboarding patterns

To lower the boarding barrier there are multiple well known patterns that you can chose or combine. Some of these patterns are listed here:

The Introduction approach shows a couple of slides and often require the user to sign up but some apps choose to show the content of the app right away. A Tutorial or a Tour approach show the real app, pointing out some example cases.

A Joy ride approach allows to use the app right away highlighting from time to time features that are new to the user. It is great way of showing what the app is all about but if your app is complex it also may be a little bit overwhelming if you do not this carefully.

A Social sign up allows the user to perform a quick sign up using his Twitter or Facebook account for example. This may be required for the user in order to be able to continue the app but it will lower the barrier if you first show what the app is about and only ask to sign up when needed to proceed.

Late sign up is a concept that is often seen in e-Commerce (and some times in m-Commerce) solutions. Only if you want to check out you have to sign up.

Anothering interesting concept is Continuous on boarding (LinkedIn for example is doing this). We want the barrier to be as low as possible but we also want user profiles to be as large as possible. The concept can be very powerful because it comes with benefits from both worlds. It lowers the barrier (by asking only for the minimum amount of credentials) and it eventually will result in rich user profiles, by encouraging the user to complete his or her profile later.

A known user is more valuable than an unknown one

Probably the best on boarding flow does not require any sign up or login, so you should ask yourself do really want your users to sign up? On the other hand it also true that a known user is more valuable than an anonymous one. In fact we are talking about users versus visitors here. And users eventually become customers while visitors probably never will.

A social sign up has multiple benefits. Not just for the user but also for us, developers. Avoid a lengthy registration process with many fields. The chance that the user will sign up increases and, with the appropriate permissions, you have instantly access to various information of that user, for example an avatar and a name of the user, which is great for personalization options.

Offering a social login could lead to 50% more sign ups. After all, a sign up is only one or two clicks away!

Use Fabric to allow the user of your app to sign up with Twitter or a phone number

There are services that will take away most of the hassle that comes with the implementation of these kind of features, such as the Fabric SDK, which is free to use. The SDK has features for signing up with Twitter but also for a sign up using your phone number, just like WhatsApp is doing.

Conclusion

It is important to keep the on boarding barrier as low as possible and also to make clear from the beginning what is in the app that your user can benefit from.

You can experiment with the different types of on boarding and see what works for your app by obtaining metrics about the conversion and learn from them. And once they are on board (activation) you can focus on optimizing the rest of the flow. Will they keep using the app? (retention) What about referrals and revenue?

As you can see, although intended for SaaS in particular, Dave McClure's start up or pirate metrics can be applied to mobile apps as well. AARRR!

Get the book!

My new book that I am currently working on, together with Arvi Krishnaswamy, is -amongst other things- about the lean startup methodology applied to mobile app development. In this book you can read more about topics such as on boarding, obtaining (actionable) metrics and split testing.

It also comes with some real world examples for both Android and iOS developers. Expect the book to arrive by the end of this year!

Further reading

• 1. User onboard, onboarding flows of well known apps described
• 2. UX Archive, onboarding flows
• 3. Fabric, sign up with Twitter
• 4. Digits, sign up with your phone number
• 5. AARRR! or: Pirate metrics

Teamcity and HockeyApp; Delivering your iOS app

TeamCity and Hockey App are awesome tools for creating a daily (or continuous) build and distribution of your iOS app. Most developers will use Xcode to create an ad hoc distribution but the Xcode command line tools are more convenient for this purpose.

For a recent project I have been using Bitbucket, TeamCity and HockeyApp to create a canary build. In addition it is using CocoaPods for dependency management. This approach works well but it takes some time to figure all things out. If something goes wrong it is difficult to find out what went wrong although in most cases somewhere in the large logfiles a clue can be found.

Building an IPA file successfully does not guarantee the signing was successful as well. So the logfile says yes but your testers or early adopters say No. For this reason it is always smart to verify if the app can be installed on a device using Hockey app.

I will tell you what I did to make the four of them cooperate and how you can avoid some of the mistakes that I have made. It goes beyond the purpose of this blog to tell you everything about TeamCity or HockeyApp, so for now I assume you already have installed TeamCity and that you do have a HockeyApp account.

Prerequisites

• You are using Bitbucket (or another Git based repository such as GitHub)
• TeamCity has been installed and configured on a build server.
• You do have a Hockey app account up and running.
• An Apple developer account.

Obtain a distribution certificate

Use the machine (your own MacBook or a dedicated build server) where TeamCity is running to create a distribution certificate in Apples developer portal.

Create app ID, add devices and create an ad hoc provision profile

Unless you have already done so you need to create a new app ID, add some devices and create an ad hoc provision profile, just like you are used to do when creating an ad hoc distribution on your development machine.

Let's create a little script that takes care of dependencies in the Pod file, building an archive and creating an IPA file, using a provision profile file. At the end of the script we will upload the app to Hockey app and clean the archive and IPA file. It is that easy. Well, once you know what is going on, things are easy...

Pod install

If you are using CocoaPods to manage the dependencies in your project (and well, of course you do !) then you need to update them on your build server as well. That makes sense. So the first of the script goes like this:

pod install

Note: If CocoaPods is not installed on your build server then you need to install the gem first.

sudo gem install cocoapods

Build the archive

The command below is what you need for building the archive for a workspace, as is the case if you are using CocoaPods.

Here we will build the sample workspace using the sample scheme. It will create a sample_ad_hoc XCode archive file in the work folder. It is the same thing as when you choose Archive from the menu in the Xcode IDE.

xcodebuild -workspace sample.xcworkspace  
-scheme sample clean archive 
-archivePath /path to your TeamCity work folder/sample_ad_hoc.xcarchive

If you have no clue about schemes (or targets) in your project or workspace. you could use the list command to find out. Execute this command in the directory where your workspace or project reside.

xcodebuild -list

- or -

xcodebuild -workspace sample.xcworkspace -list

The output wil be something like this

Information about project "sample":
    Targets:
        sample
        sampleTests
        sampleUITests

    Build Configurations:
        Debug
        Release

    If no build configuration is specified and -scheme is not 
    passed then "Release" is used.

    Schemes:
        sample
        sample-cal

Export the archive

If everything went well an archive file has been created. The next step is to create a distributable IPA file from it. For this we need to have a valid provision profile file that you have created in the developer portal previously.

xcrun xcodebuild -exportArchive -exportPath build/ 
 -archivePath "path to work folder/sample_ad_hoc.xcarchive" 
 exportOptionsPlist exportOptions.plist  
 -exportProvisioningProfile "name of the provisioning profile"

Here you need the provision profile file that you have download from the Apple developer portal. It probably will be convenient to commit the provision profile file to the repository as well.You can also download the provision profile in a different directory on the build server and include the path to it.

Note: The name of the provision profile is the name as you have typed it at the Apple developer portal when creating it (or as it appears in Xcode -if you would have downloaded and installed the provision profile by double clicking on it-). Other than you might have expected it is not the name of the file.

Distribute the IPA file

Verify if a build.ipa file exists in the work folder. If it does you can distribute it to HockeyApp. It requires an app token from HockeyApp and a Hockey app Id. Make sure the app Id is configured for uploading purposes.

Using the curl command you can easily upload the IPA file you have just created. If this is for a daily (or continuous) build you probably do not want to notify all users each time a new version is available. You can use notify=0 for that.

HockeyApp obtains the version Id from the IPA file so you might want to create an auto incremental script later.

curl -F "status=2" -F "notify=0" -F 
 "ipa=@/build.ipa" -H 
 "X-HockeyAppToken:" 
 https://rink.hockeyapp.net/api/2/apps//app_versions/upload

Clean up

Very important but easy to forget is to clean up things, just to make sure that Hockey App fails if the build fails as well. Include this in your script to remove both the IPA and the archive:

rm build.ipa
rm -rf //sample_ad_hoc.xcarchive

Conclusion

Finally your script looks more or less like this:

pod install

xcodebuild -workspace sample.xcworkspace  
 -scheme sample clean archive 
 -archivePath /path to your TeamCity work folder/sample_ad_hoc.xcarchive

xcrun xcodebuild -exportArchive -exportPath build/ 
 -archivePath "path to work folder/sample_ad_hoc.xcarchive" 
 exportOptionsPlist exportOptions.plist 
 -exportProvisioningProfile "name of the provisioning profile"

curl -F "status=2" -F "notify=0" -F 
 "ipa=@/build.ipa" 
 -H "X-HockeyAppToken:your hockey app app token" 
 https://rink.hockeyapp.net/api/2/apps/
  your hockey app app id/app_versions/upload

rm build.ipa

rm -rf //sample_ad_hoc.xcarchive

You can store the script in a file and call it in a single build step or you can create multiple build steps. With some modifications you can use also the script for Jenkins instead of Teamcity.

These are just the basics for a CI/CD flow and there many things that you could include with a script or additional build steps. What about automated unit testing? Or running Cucumber tests on your build server? That would be fun too!

Further reading

• 1. TeamCity
• 2. CocoaPods
• 3. Building from the Command Line
• 4. Xcode command line tools
• 5. Cucumber
• 6. Hockey app

7 Parse alternatives or Parse It Yourself

Last Friday it was a bit disappointing to find out that Parse will discontinue its services. It used to be my favorite mBaaS as it was perfect for prototyping but also suitable for production data. It is a scalable solution, it has great documentation and is easy to use.

Many mobile developers of iOS and Android apps rely on the Parse backend system for data storage and push notifications. The fact that Facebook has decided to discontinue it is a bit surprising as they did put a lot of effort in supporting Apple TV (tvOS) and Apple watch recently.

What is Parse actually?

Parse is a mobile Backend as a Service (mBaaS) that uses a MongoDB database to store data and Amazon S3 to store files. The Parse SDKs for Android and iOS include handy stuff such as caching and uploading data and files in the background. Other features are analytics, push notifications and cloud code, which is useful for the integration of mail and SMS functionality for example.

If you want to create a new app using a mBaas right now there are some interesting alternatives. But if you do have an app that currently is using the Parse SDK probably your only option is to use the Parse Server. Here is a tutorial to find out what you need to keep your app running on the Parse technology. Or have a look on Github where the source for the Parse Server is hosted.

Some of the features supported by the Parse Server:

• CRUD operations
• Schema validation
• Pointers
• Users
• Installations
• Sessions
• Roles

Some of the not or not fully supported features:

• Push notifications
• Facebook login
• Web based dashboard

It cannot be too difficult to reanimate most of the Parse functionality using the recently published open source Parse Server. And that is what The distance has planned to do. Well, more or less. They have plans to offer hosting for the Parse Server.

Apps on the big screen; Apple TV 4 & Android TV

We have apps on our phones, phablets, tablets and on our watches. And since recently we do have apps on TV. This year Android TV has become available and of course Apple has released its Apple TV 4, and with that, tvOS. This creates interesting new opportunities for developers (and publishers).

Both Apple and Google are aiming at streaming movies and TV series and at casual gaming but you can also think of other type of apps. So called second screen apps, for example, could be integrated into a television show directly.

On the other hand apps for TV can not be compared with apps on your phone as the interaction is completely different on television. TV apps are much more about consuming content and information and are less focused on interaction. Given this fact it will be difficult to predict exactly what TV apps are going to bring us in the future, other than movies, music and TV-series.

Apple TV

The fourth generation of Apple TV finally comes with an app store and the possibility for third parties to develop apps for it. Now Siri on TV seems to be the most impressive part of the new Apple TV, but after a while, when more apps become available, I expect these new apps to be the most interesting part of it.

The new Apple TV comes with a nice remote control. It has a touch surface and allows the user to perform gestures such as swipes, taps and clicks. A gyroscope and a motion sensor are great additions to support game play in particular. In your code you can use gesture recognizers to detect swipes and taps and there a couple of ways to detect when various buttons on the control are selected.

The remote communicates using Bluetooth and it has a microphone on board, so you can actually ask Siri about your favorite movie or TV-serie. Unfortunately Siri is not (yet) available in most countries.

tvOS

In order to develop for tvOS you will need to have Xcode 7.1. It comes with support for tvOS and a tvOS Simulator. For your TV app there are basically two approaches that you can think of.

You can create a TV app using Swift or Objective-C. Of course you can also port your existing iOS app or game. UIKit, Core graphics and Spritekit, to name just a few, are all supported. Check out this this list for more information. If you are an iOS developer already you can create a tvOS app in no time.

TVML

Another approach is TVML. It is a new process of making apps with TVML, TVJS and TVML kit.

TVML stands for Television Markup Language and is a form of XML. TVJS is set of JavaScript APIs, which provide you with the means to display apps created with TVML. Finally there is TVMLKit, which is glue between TVML, JavaScript, and a native tvOS application.

There are many, probably familiar looking templates to be found here.

Use xCode 7.1 to create a new tvOS app...

Testflight has been updated to support tvOS app deployment. The Apple TV comes with the Testflight app pre installed.

Before you start it is important to know that tvOS has some limitations, although they are not really as bad as they might look at a first glance. The app size cannot exceed 200Mb and local persistency is not possible at all. To persist data you need to use iCloud, CloudKit, your own backend-service or a mBaaS, like Parse or FireBase.

If you want to share events or data with other users, CloudKit might be a good option. If you want to create a cross-platform app you should consider using a mBaas or creating your own backend.

Android TV

Great, but what about Android TV apps? Android TV runs on Android 5.0 (Lollipop) and above and it offers more or less the same user experience as the Apple TV is doing. Media streaming apps and games are available in the Google Play Store as well.

Android TV can be built into TV's or into stand-alone media players. Hardware manufacturers, such as Sony, Sharp and Philips have or will release TVs, supporting Android TV, in 2015. Their Android TVs comes with features such as voice search and of course the Google Play Store. Android TV does also support ChromeCast, allowing a phone to select and to control media playback on the TV.

Creating an Android TV is as easy as starting Android Studio,creating a new project and selecting TV as project type. If you are an Android developer it is not very different from a common smart phone app. The main difference, as is the case for any app on TV, is the interaction. For example, the TV is not a touch screen. Besides it probably will be too far away too touch anyway.

I will elaborate on Android TV app development later. For now I am in particular interested in what the differences between Apple TV and Android TV are.

Conclusion

I think apps on TV arrived way too late as a lot of people do already no longer just watch what is being broadcasted at a particular moment in time. Instead they watch the things they want to see at the time that is most suitable for them.

Apps on TV can contribute to this new way of watching TV and it could help to integrate second screen apps (voting apps and so on).

When you compare Android TV with Apple TV you see there is not really much difference in user experience. Since Apple TV is being produced by Apple only I expect Apple TV to run more smoothly, but I must admit I have not seen Android TV in reality yet so that is just an assumption, based on experiences with Android and iOS on smartphones. And yeah, both iTunes and Google play offer movies, music, games and series. So, what actually is the difference?

Apple TV comes as a set top box solution only and despite some rumours an Apple TV TV is not going to appear soon. Android TV will be integrated in both set top boxes and TV's. I expect this will result in more people using Android TV.

Altogether interesting stuff to examine. Let's think of some great apps for TV... In the end, the app eco system determines which platform will succeed.

Further reading

• 1. tvOS documentation
• 2. An introduction to tvOS development
• 3. Apple TV App Development for tvOS on Udemy (paid!)
• 4. About Android TV
• 5. What is Android TV
• 6. New Course on Developing Android Apps for Google Cast and Android TV
• 7. Building Apps for Android TV

Your app can open doors: Host Card Emulation

Your app can open doors or make payments or do other cool stuff. Host Card Emulation (HCE) is a technology that emulates a payment or access card on a mobile device using an app. Many Android devices that offer Near Field Communication (NFC) functionality already support NFC card emulation.

A card could be emulated by a separate chip in the device, called a Secure Element (SE). Android 4.4 introduces an additional method of card emulation that does not necessarily involve a Secure Element, called host based card emulation. This allows any Android application to emulate a card and talk directly to the NFC reader.

Using Host Card Emulation you can, for example, pay, travel or check into a hotel, but you need an phone running on Android 4.4 or above.

Any app on an Android 4.4 (or above) device can emulate an NFC smart card, letting users tap to initiate transactions with an app of their choice. Apps can also act as readers for HCE cards and other NFC-based transactions.

Playing with NFC tags is fun, but HCE is even more fun...

Get started

To get started with HCE for Android you can download the card emulator and the card reader examples from GitHub (Or you can use the New, Import sample option from the File menu within Android Studio -for OSX- for that). I have installed the emulator app on an Samsung Note 3. On a second device, a Nexus 5 to be precise, I have installed the card reader app.

After enabling NFC on both devices I am able to read the 'loyality card' that exists on the Note 3 device with the reader app on the Nexus 5 using NFC. That does work great, however I have not been able to do the same with a Samsung Galaxy S4 Mini (emulator app) and the Nexus 5 (reader app). For some reason, that I have not figured out yet, the examples do not work with the combination of these (and perhaps a few other) devices.

For a Windows 10 example you might want to check this link.

Secure element

A Secure Element (SE) securely stores card data and does some cryptographic processing.

During a payment transaction it emulates a card to authorize a transaction. The Secure Element could either be embedded in the phone or embedded in the SIM card.

Pay

Google wallet & Android Pay

Android Pay or Google wallet do not (yet) use a device based Secure Element. It uses Host card emulation (HCE) instead. The card emulation and the Secure Element are separated into different areas. It can also be implemented with a Secure Element chip, but this is not yet required.

Android Pay works for KitKat users and higher (Android 4.4+)

Samsung Pay

Samsung Pay works only for a small number of Samsung devices. It is built into Samsung’s Galaxy S6, S6 Edge, Note 5, and S6 Edge+. Samsung Pay uses (embedded) secure elements (and it supports HCE).

Since it uses both NFC and magnetic secure transmission (MST) to transmit payment information the service probably will work on more POS as is the case for Android Pay.

Apple Pay

Apple Pay uses a device based Secure Element and does not use HCE. It uses the Secure Element chip on the iPhone as part of the token-generation process and also to store fingerprint data.

I have not seen Apple Pay in action yet. I guess the most nearby opportunity will be in London, where you can use Apple Pay to travel by bus, tram, railway or underground.

Apple Pay works on iOS 8 and above. The functionality is available on the iPhone 6 and iPhone 6+ only.

Windows 10 & NFC HCE

Microsoft supports HCE NFC payments in Windows 10 (mobile). You can check out the Windows 10 HCE Tap to Pay demo on YouTube.

Conclusion

HCE is interesting technology and available for Android & Windows. Apple is doing things differently and, as it seems to be, in a better and a more secure way.

Since both Android and iOS do have their own audience, Android Pay and Apple Pay could perfectly exist next to each other. And then there is Samsung Pay, which probably will become a huge competitor for Android Pay.

And what about us, developers? Well, we have some new challenges and things to figure out...

Further reading

• 1. Android card emulation example on GitHub
• 2. Android card reader example on GitHub
• 3. NFC + HCE Your phone in an interactive world (YouTube)
• 4. Write an NFC HCE app with Windows 10 for mobile
• 5. Apple pay, an attempt to demistify
• 6. Android pay, Google wallet & Samsung pay
• 7. Mobile wallets, Apple Pay vs Samsung Pay vs Android Pay
• 8. Why Samsung Pay is way better than Apple Pay and Android Pay

Mobile Behaviour Driven Development: Cucumber and Calabash

Before you will release your app to the Play Store or App Store it needs to be tested. And while we can do that manually it would be better to do that in an automated way.

Android Studio support unit testing and so does xCode. However we also have to run UI tests. Google has released the Espresso framework for this purpose. And there is Xcode 7, which also has introduced UI testing features.

But what is a smart thing to do if we want to test the same functionality for both Android and iOS? Cucumber could be the answer to that question.

Cucumber & Calabash

Cucumber is a tool that runs automated acceptance tests written in a Behaviour-Driven Development style. It describes how software should behave in plain text.

Features are being described in a feature file, like in the example shown here.

 Scenario: Login
  Given I am on the Login Screen
  Then I touch the "Email" input field
  Then I use the keyboard and type "hello@world.nl"
  Then I touch the "Password" input field
  Then I use the keyboard and type "verysecretpassword"
  Then I touch "LOG IN"
  Then I should see "Hello world"

This is not just documentation. It can be used for automated UI tests as well.

Features are being described in a domain specific language. They describe the behaviour of software without much implementation details. So these tests can also be written by the non developing members in your team.

Calabash & some glue

Calabash is a framework that you can use for running Cucumber tests on Android and iOS apps. The framework has been created by the guys from Xamarin, which makes sense I guess, since Xamarin is a cross mobile platform solution.

There is some glue code required to actually run Cucumber tests using feature files. This glue needs to be defined in step definitions and Cucumber typically lets you write these step definitions in the Ruby language. The glue is platform specific but the feature file is not so theoretically it can be used for both the Android and the iOS version of your app.

Another cool thing about Calabash is that it allows you to run automated tests in the cloud, for example by using the services of TestDroid or the Xamarin Test Cloud.

Conclusion

Seeing Cucumber tests in action is great but it may take a while before you have setup all the things you need for it.

Behaviour Driven Development sure is an interesting approach. Using Cucumber and Calabash we can create mobile UI and acceptance tests for both Android and iOS.

The downside is that in particular Calabash does not seem to be very mature yet. The tests run slow and it takes a considerable amount of time to define them. Also the mixture of Gherkin feature files, Ruby glue and Java/Objective-C/Swift code feels weird.

On the other hand the Calabash framework is still in beta so it probably is just a matter of time before mobile behaviour driven development becomes widely adopted.

Further reading...

• 1. Behaviour Driven development
• 2. Cucumber
• 3. Gherkin
• 4. Calabash
• 5. Calabash for Android on GitHub
• 6. Calabash for iOS on GitHub
• 7. The state of iOS testing in 2015
• 8. Calabash & TestDroid