I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Cameron Barrie (@whalec), Managing Director and Principle Mobile Consultant at Bilue, spoke on “how to apply solid engineering practices to your mobile applications by understanding common mistakes made, and how to mitigate against the risks.” (Slides)

Mobile: Move Fast

He said it’s crucial to be able to move fast. If you’re not disrupting, you’re probably being disrupted.

You need to be honest about what moving fast means for your organisation: you can’t start with crappy code and processes and just start moving fast.

As an example, he said reviews of apps are a really great source of truth. If your developers aren’t empowered to fix the things that customers are complaining about or asking for, you’re not set up for success.

Graham: I see the value in monitoring and responding to App Store feedback. Personally, though, I believe choosing which product features to focus on is a really important job, and I’m not sure empowering developers to react to every bit of feedback as they see fit is a good approach.

He listed his prerequisites for moving fast:

• Can you make decisions quickly?
• Are you using source control?
• Are you doing TDD?
• Does the business understand the risk/reward of moving fast?
• Do you have genuine buy-in from the business?

He noted that mobile is a new challenge for a lot of senior management in large organisations.

Deployment: Mobile vs Web

Mobile is not the web. You can’t just refresh to deploy a new version.

There is an option to do expedited releases in the App Store. They are only for emergencies. If you do them often, event for urgent bugs, Apple will call and tell you to cease or your account will be closed, irrespective of how big your brand is.

In the mobile world, there are no guarantees that anyone will update your app, and certainly no guarantee that everyone will. iCloud’s backup service stores, and will happily install, 3-year-old app packages.

He said forced updates are a terrible idea. They stop people doing what they want to do.

Graham: There is a key observation about Mobile UX here that many people miss: People use their mobiles in very different ways to other computers. They typically want to do small tasks quickly and they expect to be able to do things with very few taps and fast responsiveness. If someone wants to pay for a coffee with their phone, but is forced to update an app over 3G before they can, they will just pull out some cash.

Conclusion from the above: you need ongoing support for every public mobile release you’ve ever made, because they will continue to be used.

Backend architecture supporting mobile

Integrating mobile apps directly with backend services is a bad idea, particularly considering the need for permanent support. Solution: Create an adapter / gateway / mediator layer that is the only thing apps connect to. He said this should INCLUDE proxying connections to third-party services.

Because you can’t guarantee you can update old versions, you should remove all business logic from your app. Example: if you only get a User ID from the server, and format that into a URL for the profile, you can NEVER change that URL. Solution: Use hypermedia. Send the full URL in the response, not the User ID. Now you can change the URL at will and old versions continue working. (c.f. HATEOAS)

Version your APIs. You need the flexibility to change your API, and you can’t do it without versioning. (Interestingly, a speaker at talk I went to later this day said “Never version your APIs!”)

Mobile Deployment Pipeline: Ready to ship

You can’t control the App Store time to ship, but you can control your end. You need to be ready to ship the app at all times. How to do this: Feature flags. Bilue does them at compile time, partly for performance, but also because Apple doesn’t like code to be turned on and off in a running app. They implement this using #ifdef / #ifndef and user-specific .xcconfig files which are not checked in.

Ensure your development pipeline is heavily automated. You should have an artefact ready at the end of your build. You should be able to take any beta build, sign it (using command line tools) and upload it to the App Store.

“Continuous Deployment to the App Store is a fool’s errand. Don’t try to do it.”

Continuous Deployment works with the web because if you roll out something bad, you can roll it back straight away, but you can’t do that with apps. You can continuously deploy development versions to your developer’s phones, though.

Development Processes and Teams for Mobile Development

The soft parts of Agile are really important. You need speedy collaboration, not three hour meetings.

They use code PREviews rather than REviews – quickly describing to each other the approach that is planned to be taken before code is written.

They use pull requests to do social code reviews (by many team members) rather than supervisor code reviews. One issue that occurred with this was that pull requests would stop people’s world. Everyone would put their requests in but people weren’t spending time reviewing the requests of others. They’ve ended up assigning someone by roster to the role of ensuring that pull requests get reviewed.

You should have product-aligned teams. Mobile is not just a channel for existing products, they are a product in their own right.

“How do we get all the features off the website onto the phone app?” is the wrong discussion to be having. Done right, your mobile app will turn over significant revenue for the business. The mobile team needs business people, designers, app devs, backend devs, QA.

He finished off by saying: Keep measuring, keep learning, keep shipping.

Questions on Mobile Development

Cameron took some questions at the end of his talk.

Someone asked: “What’s your opinion on hybrid apps?”
Cameron said: Using the web seems cheaper, but it’s not as good a user experience. Considering the app will probably bring in significant revenue, there’s no excuse to skimp on providing the best experience. However, using embedded web within a native app can be a great strategy for a content-heavy app. He referred to the “uncanny valley”, the observation that for things which look almost identical to something else but are not quite the same (web apps simulating native apps, in this case), the human response is often very negative.

Someone asked: “What kind of support do you provide for old operating systems?”
Cameron said: They only support iOS 7 and 8 in their projects. Older than that, there’s so little usage it’s pointless. (Apple’s own stats show less than 3% of users on previous versions as of February 2015.) With Android, don’t just look at what versions have been sold, you need to look at what versions are being used against your app, because many phones are no longer used or were bought by people who only want to make phone calls on a cheap phone.

Someone asked: “What’s your opinion on having single apps or multiple apps?”
Cameron said he’s a fan of multiple apps. The main driver is a UX problem: how to present all your business’ different lines of business within one app, when the OS already has a simple scheme to manage that for you.

Someone asked: “Is it possible to set up continuous integration to automatically deploy, while hiding the deployment certificate from developers who have access to the CI server?”
Cameron said: TravisCI lets you encrypt certificates so that only the CI server can use it. The same can be done with Jenkins and BuildKite (formerly BuildBox).

Want to learn more?

Image credit: ‘Dubaiperspace‘ by Éole Wind