Sessions is temporarily moving to YouTube, check out all our new videos here.

The Weird World of Native Mobile

Andy Trevorah speaking at Front-End London in April, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Native mobile apps can seem weird, especially if you come from a web background. We'll go through a standard native architectural pattern and list off as many tips as we can that you won't learn in tutorials.


Andy: In my career I've made iOS, Android, and web apps. If you're going from JavaScript to native, it is a leap. It's not better, it may not be worse, but it is definitely different. There are a lot of frameworks and tech out there to give you some shortcuts so you can get your first app out there faster. These are good. You always want to prove your idea. If you're ... How many people [00:00:30] here know React? I assume quite a lot. How many here have tried React Native? Same amount? Yeah, that's good. These are great things. Because of their nature, they hide certain things away from you, just to make it easier and better, but these things do tend to come out after your first release, and things get hard. I'm going to go over the stuff that's not in the tutorials. First of all, why native in the first place. [00:01:00] I'll go over a standard native architecture in case you're wondering how things are on the other side, and then I'm just going to go through all the weird crap, because it is weird. Let's say you have a web site and management have decided that they want an app. Your web site's pretty good. Why would you even want a native app? [00:01:30] They will say that users tend to ... If they have the app installed, they use your business more. That's true. It's also a correlation, not a causation. The kind of people that have your app installed probably use your business all the time anyway, so that doesn't really count. "Push notifications improve retention" is a great one. They do improve retention. Push notifications are great. When something [00:02:00] comes in saying, "Hey, your friend Cindy has posted for the first time in three weeks," you're like, "Oh, I wonder what Cindy's up to." People start using your app and your business. You can do this in web. [Analysts 00:02:13] have shown that you can do it with a service worker. Even if you don't have those notifications coming in, you can even do it with email. People have email on their phone. That doesn't really count. The next one is ... There's probably something, [00:02:30] an API, that's really great, but you're coming from ... You've got a web site. Chances are that if you've acquired that API in order to make an app, then you wouldn't have your web site in the first place so it doesn't really count. "Users feel that they're faster at getting things done." This is pretty much the big one, than web. Also, you can put air quotes on users "feel" that they're faster, or [00:03:00] users are "faster" or "users" ... It is a very weird thing. It comes down to two things. One, you're leveraging learned behaviour. When someone uses a native app, they know that the tabs at the bottom, they're not actions. They won't start billing people for things. You can freely tab between things. That's fine. There's [00:03:30] low risk. They know where things are. They know how things work. It's more than just UI, and I'll go into that later, because it's really weird. There's a lot of non-visual patterns you'll come across. The other thing, the second thing, is that apps, native apps, are quick to show content. This is pretty much a side effect of it being great, and also apps are running in a low-memory world where they have [00:04:00] to do some weird things. If you mess up these two things, so the "leverage learned behaviour" and the "quick to show content," then you failed. Your native app has failed. Why did you build it? It's worthless. Let's have a look at native architecture. If you can't read this ... How many of you know unidirectional flow and Flux and Redux? [00:04:30] Front row of people, it seems. If you can't read, it basically is that. This has been in place since day one for Android and iOS. You can watch old grainy YouTube videos from Google I/O when it was first running about how to do this. Basically, you have your UI thing. It gets all of its state from some kind of store. [00:05:00] It's asynchronous as a query and you get query updates. That's all your state, and if you want to perform an action it goes over here. You have some kind of API service. It does some stuff, processes the [JSON 00:05:18], puts it back into the database, which is your store, the store updates the UI thing, and that is it. It's pretty much [00:05:30] just like your Redux Flux stuff, but with a database as a store and some asynchronous stuff. The magic stuff is in purple. This is what's provided by ... It's not just a database. It's wrapped up. If you ever wondered what core data actually is, it is a wrapper around database or database-like thing, and when you query it it will [00:06:00] respond with something that updates as the database and line content changes. That's what it is. Also, this red stuff, this is super cool. It is super cool because it doesn't touch any UI at all, so you're super safe, which means that you can put that in the background thread and all that happens is that the database has to handle the thread collisions, which databases are really great [00:06:30] at. Also, you do actually need to do it this way. Androids are ... When you process JSON it can ... In the UI thread, it will stutter. It will block. If you have ... If you're an Android app and you do pull to refresh and you see a loading spinner and it starts to stutter a little bit, that's because they're processing the JSON on the UI thread. You can see it as soon as [00:07:00] you notice it. Again, the list of content is pretty much just a query. If you have something that's happening, like you've sent off ... You want to add a new person, then you actually ... You send off your request. At the same time, you put something in the database that has a temporary person that [00:07:30] has a status of "in flight" or something, and it means that your UI then renders with another thing at the bottom that's ... Because of the status, you grey it out a bit so it looks like it's pending, and then when it gets confirmed you get rid of the pending thing. That's pretty much how it works. Okay, now we got that solid foundation, let's go through the weird crap. This is good stuff. Mobile radio eats batteries. If you mess [00:08:00] up ... You can have the nicest app in the world. It can print out money. It's lovely and it looks beautiful and you love it, but if it's using up your battery, people will just uninstall it. If you mess up the battery and battery usage, you're screwed. Mobile radio is the biggest drain for battery, unless [00:08:30] you're, of course, making some kind of bitcoin miner or something weird like that, but you're not. Yeah, this is going to drain it out. The reason why is because mobile radios are far away. This one's actually really small, but in reality they are far away. In order to reach them, you have to use quite a bit of power. The kind of security model around mobile radios [00:09:00] means that it has no idea what it's really doing, so it has two states. Has one high power state, and one standby state. Whenever you want to send a packet out, the mobile radio has to wake up, and then it's ... Actually, I can show you. It has to wake up. This is from a Nexus 5, by the way. It has to wake up, sends out the packet, and then what it's going to do, this long bit here, it has no idea [00:09:30] what's going to happen next and it assumes it's going to get a packet in response so it just stays awake for about five seconds. Entire time it's all draining your battery. This means that if you're polling every five seconds, your radio's never going to sleep and you're just going to drain out the battery. If you're thinking, "I'm smarter than that. I'll stream stuff. It's the same thing." You can have some keepalive packet or something going through. There's network stuff. Yeah, you're [00:10:00] screwed on that one. Don't poll. Don't stream. You got to batch your stuff up so you have all these network requests. If you clump them together then you're not going to drain the battery. It's going to have some time to just go to sleep and chill out. In order to get around not being able to poll or stream, what do you do? The answer is you push. You use your operating system's own [00:10:30] batching stuff. You can push content to your app. Your operating system is ... The mobile operating system is still actually polling, but it polls in a very smart way. It will know that ... It will wait until, say, another application is also using the mobile radio and then check to see what's changed. It will do things like, "Oh, you're on wifi? I'll check to see what's changed. Oh, you're charging? [00:11:00] I'll check to see what's changed." It just is smarter like that. I just take advantage of it, otherwise people will uninstall your app. All right. Now we'll talk about notifications. Here's a segue into notifications, and also segue, which I learned is spelled like this. Took me so ... I still do it now. Whenever I see that word, I'm like, "Seg-you." It's not. It's segue. [00:11:30] Segues are ... They're the iOS transitions between pages of stuff. They're built in. They're really great and just nice. They're pronounced "segue." Push notifications. Who here has done a push notification tutorial? That's about push notifications. One person. Two people. Okay. Was it rewarding? Was it nice? Speaker 2: No. Andy: Darn. I [00:12:00] was hoping you'd say yes, because I find them really rewarding. When you get a push notification going through, it's like ... That's cool. It's nice. Speaker 2: [inaudible 00:12:07] Andy: Did you have to do a load of code signing stuff or certificates? Speaker 2: Yeah. Andy: Yeah, that'll be it. Speaker 2: The result is rewarding. Andy: The result is rewarding. Speaker 2: [inaudible 00:12:19] Andy: Half asleep, okay. Push notifications, they're super easy to set up, but you have to remember that you need to have a way to stop them. [00:12:30] At least have a thing of unsubscribing from push notifications on sign-out, otherwise you're going to still be sending stuff that people don't care about. Like maybe ... It's a rare thing. It's annoying. Also Google and Apple hate it when [00:13:00] you're telling them that you've got notifications for apps that have been uninstalled. They really don't like that. I've never personally had them tell me that I shouldn't be doing that, but they imply it a lot in the documentation, that they'll ruin your life. Also, a really cool thing is that push and notifications are two separate things. Push is just like pushing data to your app. You don't have to show a notification. [00:13:30] Try and keep this push payload as small as you can, because it's pretty much setting up a new API and it's a hard thing to drop support for that. If it turns out that because you've got a limited payload size, and need to lose something but you know that apps ... Apps, people don't update them. You get people using the old app for years, and so it's hard to drop support. [00:14:00] Try not to have ... Just keep them small and don't break things. Notifications, they are really cool. They are the main entry point, most of the time, for your application. Like I said, you got this retention stuff where people are tapping on [inaudible 00:14:18] to see what Cindy's up to. They are also more complicated than web. This is just part of Android's notifications, [00:14:30] all this stuff that's coming in. Again, this UI also changes quite often. This also doesn't even include replies or actions on notifications. If you try and send all this stuff over the wire and your push payload, you're going to have problems because it changes. Just send the bare minimum, then do a, "Hello." Speaker 2: What's under [inaudible 00:14:58] Sorry, at [00:15:00] the top. Andy: Oh, that says "must read." Speaker 2: Oh, okay. Andy: I think it's the same as this one, subtext. It can be whatever you want. It's subtext. Yeah, don't send that stuff over the wire. Instead, send something, a notification saying, "Something has changed," and then have your app go and get all the information that it needs to construct these. Also, you will ... I've done [00:15:30] this several times. You think it'll be really cool if ... Because you're fetching all this content asynchronously, including you've got to get bitmaps for [inaudible 00:15:42] a year out you have to get the bitmap, and getting it all asynchronously, you think, "I could progressively enhance it." You show the notification of it and stuff starts popping in and you think, "Oh, that's really cool," but in reality users hate it. They hate having a notification saying, "Oh, something has changed." They open up their phone and they see they don't know [00:16:00] what it is yet. Oh, there's a little bit more. They do not have time for that shit, so don't do it. Yeah, so this is WKWebView. This is the WebView that's meant to be really good, except for it crashes quite a bit, but doesn't crash on simulators. Only crashes on real devices. That was a fun thing to find out. Also, the way it handles local content on iOS 9 ... No, iOS 9 [00:16:30] and 10, is different from how it handles it on iOS 8 in the way that it can fail and you can't see it in the simulator. I found that one out in production and I went to sleep at 4 a.m. that day. Yeah, there's a lot of weird stuff with old devices, so just buy old iPhones if you can. Seriously, if your project is going to last more than six months then buy some old iPhones, please. [00:17:00] There is some magic stuff behind the scenes for apps. You know that when you go to the app switcher, wherever you do it for Android and iOS, 90% of those apps are dead. It's more like 99%. The operating system just takes a screenshot, kills the app. Because everything's in the database, when it has to restore it, when you switch to the app, it should be pretty much instant. [00:17:30] Your database contains all your content. It doesn't contain the state you're in in terms of what view you're looking at, all this kind of stuff, and iOS and Android just do this magic stuff if you're using the native stuff. You end up having to ... When things are tearing down, you register what was actually on the screen at the time. [00:18:00] You'll get a callback from the operating system, and then when things are starting up it'll tell you, "Oh, here's the state that you gave me. Reconstruct, please," and you go through. If you're using the native stuff, this is all done for you. You end up going to the exact same screen. If you're not using the native stuff, you may find that when your app has been in the background for a while, or people just using their phones as they normally do, that your app seems to reset to the first screen. This is because you're [00:18:30] not implementing these callbacks on iOS and Android. You don't have to remember what they're called, just remember that they exist and that's the reason why things are messing up. Android back stack. I love this one. You know when I talked about the UI stuff and how there are learned patterns? It's more than just visual. Who here has an iPhone, uses an iPhone? Okay. [00:19:00] I'm going to show you some stuff on Android. I want you to tell me what happens. You got the home screen. You open ... Go down here. You have the home screen. You open the Gmail app. Here's the inbox. You open the drawer and select "important." You have the important inbox. You open the drawer and select "inbox." Back to the inbox again. Now you select an email. Now you hit the hardware back button, the [00:19:30] physical back button, twice. Where do you go? Votes, please. Anyone, say anything. Speaker 3: Forwards. Andy: Forwards? No. Speaker 3: [crosstalk 00:19:41] Andy: Important inbox? Home screen? That's crazy. Android people, can you just have a look on your phones? You definitely have Gmail. You have an Android phone, seriously. [00:20:00] Okay, just to save time, it is ... You go all the way back to the home screen. You can have a look to confirm for yourselves, if you want. It's because it's really weird. There's a hierarchy in your mind of how the app is meant to be. The inbox is a primary thing, the viewing email and the important inbox are secondary. When you're going back [00:20:30] twice, like you're going back through the hierarchy, it's not ... The back stack isn't a history, it's a thing in your head. The weird thing is that it's not how ... It makes sense when you're using the app, but it doesn't make sense when you're developing the app. Your users expect this hierarchy, and if you don't have it, then you're going to end up with two-star reviews, [00:21:00] that kind of stuff. It's a weird thing that they know how deep into the app they are. Talking about reviews, this is the last bit. Probably the most important, maybe, except for the battery, I guess. App reviews are important, but they are incredibly draining. [00:21:30] They are really ... When people go to instal your app, they will see the reviews. They will see that star rating and based on that star rating they'll choose, "Maybe not." You need to have good reviews, but these bad reviews can really affect your mental health. You have to check on the reviews all the time, but it just drains. [00:22:00] Again, you're going to receive negative reviews. In general, when you release an app, you'll get positive, "Hey, this app exists, it's great," for about a week, and then you just have this ... It's almost like a rot, where you'll just slowly go down. Sometimes like this way. It's hard, but you got to remember [00:22:30] that version one of your app, if you're a good developer, version one of your app will be the worst version of your app. That just makes logical sense. There are ... Also, the complaints are usually quite valid. Sometimes they're just dicks. I'm just joking. They are very valid. Individually, they will affect your work. If you're checking the reviews, if you ping in, and probably through [00:23:00] your day you just hear, "Oh, your app is shit," it's like, "Oh." Here's how you deal with that. The way you deal with it is you tally up the complaints. When reviews come in, "Your notifications suck," do this all in one go so you just scroll through the app store reviews and just tally them up. "Drains battery," "notifications still suck." Keep on going. Usually they tend to come together, and at [00:23:30] this point you know that, "Okay, the worst thing about our app is that notifications suck." That's probably the next thing to work on. This is great to bring in to planning and iterative development. Also, again, it's good for your mental health because you just get it all out of the way at once and it just has less meaning. It's also super satisfying when you actually fix that thing and you go to the App Store. [00:24:00] You can reply to reviews. There can be some mean people, but when you reply saying, "Oh, I fixed your thing," they love you. It's the greatest thing. Really, really, really makes my week. Hopefully this doesn't deter you, but remember having bad reviews is better than having no reviews. When you're having your version one of an application, just get it out there and try [00:24:30] it. That's the whole point. You're just seeing if people actually want this. If they don't, then leave it. That is the end of my weird stuff. Speaker 4: That was a really great talk. Andy: Thank you. Speaker 4: It was hilarious and stuff. Does anybody have any questions for Andy? [crosstalk 00:25:00] Speaker 5: [00:25:00] Yeah, I was intrigued by some of the slides with the app processing. Those are [inaudible 00:25:08] apps. Some of those workflows are quite complex, aren't they, compared to ... It's not quite a question, but some of those complex [inaudible 00:25:17] really ... I was trying to follow some of those and work and it's really quite tricky. Andy: Yeah. I guess the thing is, with applications, applications existed before the web, [00:25:30] and so this whole offline thing, offline first thing, they are just offlines. They end up all having some kind of database where there's a file or whatever they're working on, and the networking adding onto that just ... You're going from first to fourth or something. Yeah, it is complex. There are some things to get round it, like you can use reactive [00:26:00] programming, so like RxJava and that kind of thing, where you just take some of that away from it, but yeah. Speaker 5: [inaudible 00:26:10] it was interesting to compare it to what we deal with in web and [crosstalk 00:26:16] Speaker 4: We got a question over here. Speaker 6: Just quickly, you talked a little bit about battery usage with network requests with the cell towers. Andy: Yeah. Speaker 6: I [00:26:30] went to a talk [inaudible 00:26:31] when I talk about it I find it really interesting. Back then WebSockets never existed. I'm wondering if you know much about realtime apps and how WebSockets are with battery usage and on mobile. Andy: I don't know. I guess it depends on the implementation, but every time that I've done streaming there's always been some kind of keepalive thing, which means that [00:27:00] packets are being sent out. Maybe there is a way that you can keep a socket open that doesn't involve the mobile radio, but what you can do is you can try it. Android and iOS have decent reporting, so you can actually see battery usage over time. I think Android has some really good things where it just shows up as individual blocks in your debugger, in your timeline. You can check for yourself to see if it's actually draining [00:27:30] the battery. I honestly don't know right now. Speaker 7: Which are your apps in the App Store? If we want to go and leave really nice comments ... Yeah, just make you feel really good about yourself. Where should we go? Andy: No, I feel really bad. Currently I work for the Times, so the Times, I guess. I've only just started. It's all right. The [00:28:00] interesting thing is there are apps that internally, the developers just hate. "Oh, it's the worst app," but users actually love, and some amazing five-star reviews ... Yeah. For some others ... I'm not going to tell you them, because otherwise ... Speaker 4: Are you native native at the Times or are you React Native at the Times? Andy: At the moment I'm doing some React Native at the Times. At the moment it's native native, [00:28:30] but we're seeing what we can do with React Native, just because it's duplication of effort. There are some parts that I think React Native are really good for. Navigation is not one of them. That's just my personal thing. I've seen too many React Native apps where things like the back stack doesn't really work right, people have made assumptions about how things should be, you end up with trying to have a one-size-fits-all thing. Just for navigation, [00:29:00] it doesn't work out, but for individual almost pages of things, React Native is perfect. Speaker 4: Yeah, we've been using it a lot recently and it's great for getting your product off the ground, but then there are also huge caveats. Does anyone else have questions before I ... Okay. Thank you, Andy.