11. Provisioning
• Apps running on device must be signed
• Registered developers
• Complicated provisioning setup
12. Volatile environment
• New technologies every year
• Users are constantly updating their devices
• Not the gold rush it used to be
• Keeps you on your toes
14. App Stores
• Main (and mostly only) distribution channel
• Apple says 65% of downloads come from search
• Opaque ranking system
• Hard to optimise due to limited amount of data
• User acquisition is hard and expensive
Source: https://developer.apple.com/app-store/search-ads/
15. App approval times (iOS)
• Most apps are now reviewed in 24
hours
Source: appreviewtimes.com
0
20
40
60
80
1 2 3 4 5 6 7 8
30. Release every two weeks
• An experiment on process
• Focus on focus
• Keep a continuous stream of updates
• Fixes are not hostage of moving release
dates
• Process not new but not common on small
teams
34. Continuous Delivery
• Every change can be pushed to the store
• Built over our CI
• Test builds
• UI tests
• Deployment pipeline
• HockeyApp
• TestFlight
• Release
35. Fastlane
• Toolchain for Continuous Delivery
• iOS
• A bit on Android
• Streamlined process
• Moved separate scripts under Fastlane
lanes
• Adopted Match for simpler code signing
37. Moving faster
• 7 releases in Q2 vs 3 in Q1
• 5 experiments launched in Q2 vs 2 previously (Q1 & Q4’15)
• Smaller yet bolder experiments
• App Store features diluted some metrics
38. Quality & User satisfaction
• “Move fast and break things”
• Positive trend in reviews
0%
0%
1%
1%
2%
2%
November
December
January
February
March
April
May
June
Crashes/Sessions
39. Quality & User satisfaction
• “Move fast and break things”
• Positive trend in reviews
1 stars
2 stars
3 stars
4 stars
5 stars
6 stars
November
December
January
February
March
April
May
June
iOS Android
I’m a software engineer who has been building iOS apps since 2010.
I also graduated at this school and I’m very pleased to be here today speaking to you all.
I don’t know how many of you have heard of GetYourGuide before Commit.
GetYourGuide is a marketplace for tours and activities. We sell tours but we are not a tour operator!
Simpler is maybe to put you all in an hypothetical situation:
consider you are in Porto for a conference and you have your Sunday free to get to know the city (pause). In this case you can check getyourguide.com and find the typical bus tour around the city, a wine tasting experience or a relaxing tour in Douro river from where you can enjoy the gorgeous views of both Porto and Gaia river shores.
For any activity you can read user reviews and book on the go, from your phone, and pay with Paypal or credit card. Our app also helps you find your way to your booked activities and act as your ticket!
GetYourGuide is a startup in the travel industry that has built an online marketplace for tours and activities that can be booked in advance.
Largest online catalog for tours
[platform to sell activities / more than 26k activities in N countries / 14 languages / user markets: Europe / UK / Australia / USA / Asia / Latin America]
We have engineering offices in Berlin and Zurich.
Our small apps team, has 4 front-end engineers, 2 per platform, and a back-end engineer, alongside a product manager and a designer.
This talk is going to share our experience as a small team working on a tight release schedule for native apps in the travel industry. I’m not here today to show a recipe for success.
Apps crash easier than webpages
Not your regular front-end developer
Last 14 days
We at GetYourGuide aim to build our products around experiments and hypotheses.
Hard to acquire users to get data
Release process was overlooked because it didn’t happen so often
Big teams like Facebook are doing this for some years now (many engineers working on the same app)
If you have a big team and want to understand how this impacts you, there is a nice blog post from Facebook from 2012 and a very nice talk from a Spotify iOS Engineer from UIKonf 2015. They go into more detail on the benefits this brings on bigger teams.
3 months ago we decided we need to change something.
As an experiment, we decided to impose a hard deadline on all of us. Every two weeks we’d be releasing an update for the app with whatever is ready to be released.
<why defining a constraint on the release time?>
From there it was easy to identify some things that would help us achieve that:
we traded our quality checkpoints for feature toggles;
some of our processes needed to happen more often, like localisation, automated testing and test builds;
copywriting and translating release notes was now a bigger burden and we didn’t need it.
3 months ago we decided we need to change something.
As an experiment, we decided to impose a hard deadline on all of us. Every two weeks we’d be releasing an update for the app with whatever is ready to be released.
<why defining a constraint on the release time?>
From there it was easy to identify some things that would help us achieve that:
we traded our quality checkpoints for feature toggles;
some of our processes needed to happen more often, like localisation, automated testing and test builds;
copywriting and translating release notes was now a bigger burden and we didn’t need it.
3 months ago we decided we need to change something.
As an experiment, we decided to impose a hard deadline on all of us. Every two weeks we’d be releasing an update for the app with whatever is ready to be released.
<why defining a constraint on the release time?>
From there it was easy to identify some things that would help us achieve that:
we traded our quality checkpoints for feature toggles;
some of our processes needed to happen more often, like localisation, automated testing and test builds;
copywriting and translating release notes was now a bigger burden and we didn’t need it.
We found we were actually moving towards a continuous delivery setup.
I won’t cover much about CD as João has already covered much of the topics that provide you with the right context. I’ll just highlight what I believe is relevant for our use case.
We had some CI in place with commits and pull requests to master triggering some automated builds;
We had a deployment pipeline with HockeyApp and TestFlight, this one for iOS;
We had user acceptance tests both automated and manual;
We needed to do it faster and more reliably.
We moved to Fastlane to streamline the release process.
We started using Match to simplify signing.
Started as a list of scraping tools that interacted with Apple Developer dashboard
Now has a very comprehensive list of tools for shipping stuff
Again, we are a small team. We believe the benefits would be an order of magnitude greater if we had double the size.