I'm excited to share that Building Mobile Apps at Scale: 39 Engineering Challenges is out. It's my first-ever paperback book and one that is free as a PDF for the rest of the month[1].
I had worked for years at Uber, first as a mobile engineer, then an engineering manager. Despite being a mobile-first company, I could not shake the feeling that non-mobile engineers and managers consistently underestimated the complexity of large-scale mobile development. I've been in so many meetings where an engineer, a PM, or a director would say, "oh, compared to the backend, the mobile part should be simple enough... it's just another frontend, right?".
I found myself explaining again and again to PMs, engineers, and stakeholders all the hoops the mobile team needs to jump to ship things in production. How mistakes are very expensive - and thus, we need to ship almost all changes behind feature flags. How the build train means that the changes we make today will take at least 2 weeks to get to prod. How devices being offline is something we need to actively support, and anticipate... and so on. I noticed similar "aha moments" each time. Talking with other mobile engineers in similar environments, they were having similar conversations, and battling similar assumptions on mobile being relatively simple.
I had been collecting the numerous challenging areas that I planned to publish as a blog post. After I shared the draft on Twitter[2], I got an unexpected amount of interest in people offering to contribute. The contents became too long for a post, and so this book was born. Several people asked for a paperback version[3], and I decided to create the book in print as well, as I felt the contents warranted it.
I hope you find this book useful - both if you're a mobile engineer or if you work with mobile teams. And I'd love to hear any feedback!
"I've been in so many meetings where an engineer, a PM, or a director would say, "oh, compared to the backend, the mobile part should be simple enough... it's just another frontend, right?"."
I've heard that before too. Even before getting in to the various engineering issues between different platforms, if you're talking about 'native apps' - things to go in to an app store - specifically apple... that "it's just another front end" line is beyond laughable.
The effort involved in simply packaging up a handful of mobile apps for distribution in app stores - between multiple icons, splash screens, basic device testing... is often a level beyond what people who've not worked in mobile have ever had to deal with it - especially internal 'line of business' app folks.
I say this as someone who's only done a small number of mobile apps (some angular/ionic years ago), and looking recently, it's only worse.
"I've been in so many meetings where an engineer, a PM, or a director would say, "oh, compared to the backend, the mobile part should be simple enough... it's just another frontend, right?"."
You sold me on the book with this sentence alone. =)
>I've been in so many meetings where an engineer, a PM, or a director would say, "oh, compared to the backend, the mobile part should be simple enough... it's just another frontend, right?".
Oh my. As an Engineering leader, I've had this conversation many, many times.
>> I've been in so many meetings where an engineer, a PM, or a director would say, "oh, compared to the backend, the mobile part should be simple enough... it's just another frontend, right?".
My answer for that usually: "Have you ever noticed any project typically has 90% bugs on frontend?"
congrats on publishing! it was SUCH a good read and incredible quality. Absolutely recommend that everyone get it before the free period runs out, and then buy the full edition anyway because it is that good.
Having read the book cover to cover I can say that it is quite a well made, relatable list of challenges and how they are being resolved in the sector. Foreseeing these types of issues is hard especially if you never went through the process, and quite hairy to resolve as such I believe it is a very good resource to have.
On another note each section comes with quite a lengthy follow up material, which I found absolutely amazing to use as a starting point as well.
Everything Gergely writes (and he writes a lot! Books, blogs, tweets; and also YT channel) is gold, especially if you're into mobile dev, interested in growing as a senior developer, or if you live in Europe and are interested by big tech. He's really filling a huge gap.
Re:book, I've been an Android dev for 3 years (hybrid & native) and the book really covers the whole spectrum of things (as you can see in the table of contents) that need to be done to have a good app, some of them hard to know in advance. At the same time, it can (and should) be read and understood by non-devs (project managers, directors etc.). Congrats on the launch!
Congratulations on publishing! And on a unique topic at that.
I’ve built, and than managed teams building, apps of large scale and complexity. Your outline looks like a goldmine of practical and essential advice, especially for folks just ramping up on mobile. I’m excited to give it a read.
Ran into same issue. What worked was the first email that gives you a link to gumroad. After using the coupon and providing an email to gumroad, it showed me the confirmation page, but didn't send me an email for the PDF.
The fix was to go to that gumroad confirmation page, and where it says "enter a password" (basically it'll create a gumroad account) you'll then be able to login and check your gumroad account, book should be there.
Ouch. Feel free to email me on this [1] email address and I’ll help sort it out.
Gumroad has fraud protection for free “purchases” as well and I’m also filtering out domains that are known to have high bounce rates or not valid domains.
Congratulation on the publication. I remember meeting you in Amsterdam Uber offices for a casual chat and coffee and really enjoyed our conversation. It was pretty neat that you were willing to nerd out with a rando from US over distributed systems and payments :)
> Bugsnag have published metrics on what median app stability scores look like:
> 99.46% for apps built by 1-10 engineers
> 99.60% for apps built by 11-50 engineers
> 99.89% for apps built by 51-100 engineers
> 99.79% for apps built by 100+ engineers
I find it amusing that reliability goes up when the team hits 11 engineers, then again when it hits 51 engineers, but then dips when it hits 100 engineers. Need to finally read my copy of the Mythical Man Month.
This one was both surprising to me, but having worked on an app with >100 engineers, also less so.
The challenge is how with 100 engineers you typically still want to ship 50-100x as much as with 1 engineer. And all those small features that the 1-3 mobile eng-sized teams work start to have unwanted/unexpected impact on each other, bringing down collective app stability.
Also, the >100 Engineer apps are typically used globally, with often millions of users. Many of the crashes will come on Android, on exotic hardware / old OSes, in my experience.
It's interesting that the paper version doesn't include "Growing as a Mobile Engineer" - too much paper and/or logistical issue? Trying to decide which way to support you, congrats!
Doing a paperback version for Growing as a Mobile Engineer would have been additional work I wasn't ready to take on.
And the paperback distribution is done through print-on-demand, so I can't bundle a digital book with it.
I say go for whatever is more useful to you: two ebooks, or a print book.
For transparency, the $20 bundle bought online nets me $19 (Gumroad fees are 3.5% + 30¢), while the $22.50 print book will be around $9.50 (Amazon shares 60% of the revenue, plus I pay for the printing of about $4/book). The $22.50 Kindle book on Amazon nets $7.70 (Amazon pays a 35% royalty on Kindle books above $10).
Thanks for the great work on collecting this material. There are many gems here!
Chapter 18. speaks about "Manual Testing". Do you have any references on how to manage test plans? These are helpful if
It's not really mobile specific, but I could not find advice in the references provided and the tooling landscape looks rather grim.
When I was at Uber, a team built an in-house system where people/teams could record a series of steps, then someone else could mark them as complete or failed with comments. It worked surprisingly well for our use case (execute all sanity tests every week - throw in email reminders, integrating with the build train (to not release to the app store when a test fails), and to the alpha/beta fixing process.
I am unsure what is available as off-the-shelf in terms of tooling though.
Zephyr, Xray, TestRail are commonly used, but all of these feel clunky. Azure DevOps has some tools that looks promising, but I have no experience using these.
I'm thinking mobile apps are a thing of the past. But writing a book is a hell of a job. I did it once, it was hard, as hell and the everybody pirated it.
> I'm thinking mobile apps are a thing of the past.
Do you think this is the future or actually happening right now? Because as an iOS developer I've seen zero reduction in work since close to a decade. What I have not seen, is people favoring web apps.
I mean I could be totally wrong but, it is my perspective at least.
I’ll share my perspective from working in big tech. Mobile apps aren’t the sexy tech they once were (like in 2012). We do have mobile apps critical to the customer experience. Even the same app may have some components or features built natively, using some framework (React Native), or html rendering. And these apps are supported by dozens or more teams across organizations.
Delivering this at scale is hard. And big tech likes to launch things quickly, and so you might see something that’s an obvious thing to fix… but it turns out that changing that one thing will break several other things. There’s no single holistic architecture even within one distribution of the app.
It doesn’t really matter if they’re a thing of the past. Mobile apps aren’t as novel anywhere - your customers expect a mobile app. That actually raises the stakes because making the wrong architectural decisions is going to be very costly in the future as your business has to scale or might even straight up prevent your business from becoming successful in the first place.
> I'm thinking mobile apps are a thing of the past.
They _should_ be mostly. Apart from push notifications and 3D rendered games and cutting edge apps using phone tech that isn't available in html - very few apps in use today couldn't be published as a PWA.
"App Store discoverability" its totally a thing people want though. You can't publish/find PWAs in Apple's App Store.
>But writing a book is a hell of a job. I did it once, it was hard, as hell and the everybody pirated it.
You probably know this, but don't get _too_ disheartened by that. Very few of the sort of people who happily pirate books would have paid for them anyway. Same as how the movie/music industries claims of billions of dollars lost to piracy are just self serving hyperbole bullshit.
I find at least as big a driver from our clients is that until webapps case be searched/discovered/"installed" from the AppStore, businesses still want mobile apps.
I've also heard war stories of people who built PWAs for Android and published them in Play Store, then wrapped them with Cordova to make a "native" iOS app, only to have it rejected from App Store because the reviewer found the PWA/website and used the "apps must be 'beyond a repackaged website'". :sigh:
Thanks! Yes, I used both, and one of the founders of Linear App was a staff mobile engineer at Uber, where we worked together.
Bugsnag is mobile crash reporting and Linear App project management (not specific to mobile, more like an alternative to JIRA). I see zero overlap between them.
It does discuss feature flags and touched on navigation approaches and the challenges with these. It doesn't touch on coordinators per say: it's one of the many patterns you can use.
I had worked for years at Uber, first as a mobile engineer, then an engineering manager. Despite being a mobile-first company, I could not shake the feeling that non-mobile engineers and managers consistently underestimated the complexity of large-scale mobile development. I've been in so many meetings where an engineer, a PM, or a director would say, "oh, compared to the backend, the mobile part should be simple enough... it's just another frontend, right?".
I found myself explaining again and again to PMs, engineers, and stakeholders all the hoops the mobile team needs to jump to ship things in production. How mistakes are very expensive - and thus, we need to ship almost all changes behind feature flags. How the build train means that the changes we make today will take at least 2 weeks to get to prod. How devices being offline is something we need to actively support, and anticipate... and so on. I noticed similar "aha moments" each time. Talking with other mobile engineers in similar environments, they were having similar conversations, and battling similar assumptions on mobile being relatively simple.
I had been collecting the numerous challenging areas that I planned to publish as a blog post. After I shared the draft on Twitter[2], I got an unexpected amount of interest in people offering to contribute. The contents became too long for a post, and so this book was born. Several people asked for a paperback version[3], and I decided to create the book in print as well, as I felt the contents warranted it.
I hope you find this book useful - both if you're a mobile engineer or if you work with mobile teams. And I'd love to hear any feedback!
[1] https://www.mobileatscale.com/#pricing
[2] https://twitter.com/GergelyOrosz/status/1335305213394251780
[3] https://twitter.com/elevenetc/status/1335595203411972097