The panelists discuss cross-platform programming and devices with Chris Stevenson

 

Jaim, do you have a hard stop?

A mildly hard stop.

Oh, okay.

[Chuckles] I could hear you categorize it.

How do I say it correctly?

Semi-firm – I don’t know.

No, not semi-firm. Let’s see – no, no, not that [chuckling].

Spongy, but not like latex, not like a bath sponge.

Yeah, that’s about it.

Hey everybody and welcome to episode 80 of the iPhreaks Show. This week on our panel we have Jaim Zuber.

Hello, from Minneapolis.

Pete Hodgson.

Hello, from Coit Tower.

I’m Charles Max Wood from DevChat.tv, and this week we have a special guest and that is Chris Stevenson.

Hello, from San Francisco.

Chris, do you want to introduce yourself really quickly?

Yeah, I’m CTO of a small startup called Applauze. We do iPhone and Android apps. We started doing music discovery apps on iPad primarily; we had an app called History of Jazz, followed by Road to Woodstock – very music-centered. Then we did a Mac music discovery app called Band of the Day, which was literally what it sounds like. You get a band every day with some content and music to listen to, and some stuff to read about the band, and that was done on iOS and Android.

Subsequent to that, we now have an app called Applauze, which we renamed the company to match, which is about buying tickets. We have an iOS app that’s been out for a couple of years now and we are literally at this moment finishing up the Android app, which will be released later this week.

Before I was an iOS-Android mobile developer, I was a consultant at ThoughtWorks actually with Pete Hodgson for quite some time. Spent nine years traveling around the world, doing all sorts of random software development, which has been a great experience in terms of meeting people and seeing how things are done around the place. It’s nice to be settled in one place after such a long time of traveling and working in mobile, which is I think the most exciting part of software development right now – unless, of course, you’re landing on a comet somewhere, which is also happening as we speak.

That’s one of the tough gigs to get though.

Yeah.

What, writing mobile apps or landing on comets?

Both, kind of. People would get more of a shot with mobile apps.

I saw an awesome vine today showing the team of scientists that were landing it and celebrating just after the harpoon went in or whatever. I’m pretty sure at the next conference talk I give, I’m going to use that gif at some point. It’s just a bunch of geeks high-fiving each other and hugging – it’s pretty awesome.

The thing that surprises me about those events is that these people have been working for 15-20 years on this one thing, and getting to the point where it’s a make or break moment at the end of that is insane. I mean, that’s your life’s work right there. It makes what we do seem fairly prosaic in comparison.

Yeah, it’s even worse than the App Store [chuckling].

I just want to see one of those guys shooting the harpoon at the comet, looking like Captain Ahab [chuckling].

I have one quick announcement before we get going too far, and that is that I finally have the website up for JS Remote Conf. If you’re into JavaScript – I know this isn’t the show, but I know that there’s crossover between the shows. If you’re looking for a conference experience where you don’t have to pay for travel – you don’t even have to leave your house; you can watch with your bunny slippers – then go to jsremoteconf.com. The price is actually pretty low too, so definitely check that out. We’re putting together a program in the evenings so you don’t have to take work off either. We’re removing as many barriers as we can to that. Anyway, that’s all I’m going to say about it.

What is there to Applauze – by the way, I’m watching the little video where it shows you the app and the battery’s almost dead on the iPhone. But besides that, what is there to Applauze that interesting that we can talk about as far as how it works and things like that?

I think what’s interesting to me and relevant for iPhreaks is I’ve worked a lot on backend systems and enterprise systems, and I’ve come into mobile as I’ve realized that that’s my passion. What I’ve done recently is I wrote – pretty much the solo developer for a long time on Band of the Day on Android, after having written it for iOS. Now I’m leading the team that’s building the Android version of Applauze after having worked on the iOS version.

One thing that’s interesting to me is how are the two platforms similar, how are they different, what we can learn from each other in a positive way rather than the kind of general iOS-is-better-thanAndroid stuff that we hear so often on the blog and in the pubs around San Francisco. I think as well, I’m interested in looking forward as to what’s coming next in mobile, and I think obviously the announcement of the Apple watch version the Android gear and the Android ware sort of platforms are interesting in terms of what we should be looking out for next in the way that people use our software on mobile devices.

I think that's a really interesting topic for me, talking through what we can learn from each other, or things that you miss when you’re developing on iPhone, the things that you miss on Android and vice versa. I’ve not gotten a chance to do that much Android development, but I’m sure there are some stuff that’s better on that platform or some ideas on that platform that would be good to see on iOS.

I guess I wonder how much stuff there is that we could, if we wanted to, bring to iOS from Android, like what stuff we could build an open source equivalent app, for example.

Yeah, I think that’s an interesting question. The thing that interests me about Android, there’s quite a different philosophy when it comes to the way that you interact with the devices.

A good example would be, say, messaging or sending an SMS. If you’re on Android, any app can ask permission to have access to your SMS, to sending messages, to those sort of functions on that app, and that permission is asked for when you install the app. It’s not at the time of use; it’s at the time of installation.

People can tend forget that they’ve given permission to something to send SMSs. On the evil side of the spectrum, that means that there have been malware apps – or Trojans, if you like – that will send out expensive messages to pay-per-use SMS endpoints. They get taken off the store, obviously, as soon as they’re found, but they do exist.

On iOS, the whole philosophy of sharing is quite different. Any app can send an SMS, can send a message, but it goes through the central iMessage app and it pops up – it always pops up – the iMessage app so that the user can decide what they want to send. They can edit the message; they can decide whether to send it or not to send it. In fact, the app doesn’t even find out if the user eventually sent that message of not. That’s just one example, but it goes through the whole platform, if you look at the way that emails are sent. If you look at even the way that Facebook updates are sent, there’s an expectation and I think it’s – for the memory part of the iTunes agreement that we all clicked through, that when doing something on behalf of the user, you always have to ask that user beforehand. You can’t just send something off without them being able to edit it or review it or whatever.

That obviously means that there are some things on Android that are actually much easier to do. For example, many apps will now authenticate your phone number by sending an SMS in the background and receiving it, and checking that it’s received, and then you never have to interact with our SMS app or whatever. So there are some things that are easier using that model, but there are definitely some negatives as a user. Anyone want to comment on that or should I just go on? [Chuckles]

To me, it feels like Android development or the Android philosophy is more developer-centric and the iOS is philosophy is more user-centric. It does make it a lot harder to do; it sounds like what you’re saying is it makes it harder to do some stuff on iOS as a developer, but as a user, I’m way more in control.

Yeah, I think that’s true. And I think this is actually key to Apple’s DNA; it’s actually fascinating to me. If you go back and look at the classic Steve Jobs keynotes over the years, there’s always a point there in the keynote where he says, “We care about you, the user. This is what we want to do – we want to make a delightful experience for the users.”

The truth of the matter is, that’s not marketing speak; that’s in the DNA of the company. What’s interesting is, if we think about it, Apple had been giving away their trade secret for the past 25 years. The fact that they’re still at the top of their game is testament to how hard it is to actually recognize that’s their trade secret and actually follow up on it.

It’s interesting as well – I mean, it’s fascinating at the moment because Google basically drives Android development, and the thing with Android development is Google makes money off ads.

There are features that you might want as an Android user that Google will probably never going to build.

For example, in Safari you have the mobile reader view where you can get rid of all the ads and you can just get a nice, readable view of the content. That doesn’t exist in Android Chrome, and it doesn’t exist because it’s Google and they want you to see the ads. It’s kind of fascinating to me, how the DNA’s of the two different companies form the way that the platforms are developed and developing.

There’s other examples like – another good example is Passbook versus what I guess is the closest Android equivalent which is Google Now. Passbook, of course, if I want my –. I went to see Interstellar last night and I get my tickets through Fandango and if I wanted to put that into Passbook – I don’t actually know if you can on Fandango, but let’s assume that you can – I would say, tap on something and it would add them to my Passbook. Then the tickets are in my Passbook, which is what I show when I get to the theater.

On Android, it’s actually in Google Now. What that means is if I’ve got a Gmail account, then Google will scan my email, will recognize the fact that there’s a receipt from Fandango and will take that and display it in Google Now. In some ways it makes Google Now much more powerful; it can show things that I’ve never told it about officially, but it also ties it specifically to Google services like Gmail, and it can sometimes be creepily magic. You will search for a flight number and the next day, Google Now will tell you when that flight is arriving – which is useful, but also kind of creepy.

It comes back again to that whole user-centric thing on iOS where the user has to consciously make a decision for something to happen, so there’s a bit more of a mental model in the user’s head of how this stuff is happening. It’s not a “Oh that’s there because I tapped it” sort of thing.

I think another example of that difference in mentality is the way that the app stores work. Google are very algorithm and data-centric, and they’re obviously very good at scaling, right? They would never had considered the idea of having a human being involved in every single app review process because that doesn’t scale. Whereas Apple are very – well, I won’t say that they’re not good at scaling [chuckles] but Apple are very centered on the user and so they think it makes sense to have a human to make sure that the user is going to get a good experience from every single application.

Yeah, that’s something that we thought about in Applauze as well if I can switch back to what we do. When we sell tickets, we want to be more than just a ticket-selling store, for example. We want to be more like a concierge service, so we want to be able to remind you when the event comes closer. If you have questions about going to the event, there’s a chat interface where you can talk to our customer support about how you get your tickets, or are they on the way, or “I’m at the venue, where should I go?”

We thought for a while about making that algorithmic, and then we thought, “Well, actually we’re an early-stage startup. We should learn how to do it by hand first and we should be having conversations with our customers as much as we can.” So we do that – we try and scale the human factor, I would say, rather than trying to make everything algorithmic from day one.

A lot of that curation is done by hand, and obviously that implies that we have to build tools that help people curate things quickly, but at the same time, it means that there is still a human touch to it. I think that's something that I think is a happy medium between something that’s purely algorithmic, and something that actually still maintains a bit of quirkiness and a bit of humanity.

It might be worth even mentioning – going back to examples – Siri versus Google’s voice stuff, which doesn’t even have a name. Siri definitely has a personality, whereas “Okay, Google Now” is kind of very machine-like and robotic. Just different philosophies, I guess; different kind of feel.

So having gone through two different apps – you built the iOS app and you’re doing the Android app – a question I always get as an iOS developer is, “What about the cross-platform tools?”

For a year, we’ve been fighting this off, saying, “It really doesn’t save money. Performance is not there. The platforms are too different to make a good experience,” and that’s what we’ve been saying for a few years, and we’ve been fine with that. I’m just wondering if your views on that have evolved and if so, how so?

That’s a really good question. I have always felt that developing – using the native tools is the right way to go. That’s from conversations I’ve had and from the experiments I’ve done that still seems to be the case.

I know people who've worked with some of the cross-platform JavaScript frameworks, for example – PhoneGap was one of the earlier ones where you’re embedding essentially an HTML page inside a very thin app. That, I think, just leads to uncanny values on both sides of the fence, on both Android and iOS. They’re different platforms – they feel different, and they should feel different.

If you build something that’s just a thin wrapper around HTML, well, first of all, you’re going to have performance problems because it’s not the same as running it in a browser. Secondly, you’re going to spend a lot more time trying to tweak JavaScript to make it feel more native because people will use your app and they will get this feeling of uncanniness because the scrolling doesn’t work the same way, or the flick doesn’t work the same way, or rubber-banding is not quite the same. Your focus shifts from building a product to actually trying to make something that feels native, which is pointless.

Our apps are all 100% native. As someone who’s worked on the backend and the frontend, I tend to write a lot of the initial code for the API communication layer and maintain that across the different apps. The interesting thing though is – and this is as close as you can get to a natural experiment – having worked on the iOS version of Band of the Day for example, and then worked pretty much solo most of the time on the Android version of the app, I can tell you that it took us four months as a team of four people to develop the first version of Band of the Day.

The first version of Android of Band of the Day was done in about three months, solo, by me – and that’s not because Android is a better platform to develop on. It’s not at all that; it’s that all of the hard decisions were already made. All the decisions about interaction design, all of the decisions about look and feel, about the kind of assets, how the backend would work, how the users would interact with the device – all those decisions were already made, and that's where all of the time is spent in development. It’s not in building screens; it’s not in building API communication layers and things like that.

Having said that, I think there is a potential place for frameworks that can be reusable across the API layer. It’s funny to talk about a mobile app as a multi-tiered app with a backend and a frontend. You’ve got the view and you’ve got the communication layer that talks to the backend, but they are actually multiple layers. That backend layer is obviously not directly visible to the user, and they’re much more amenable to cross-platform development.

We’ve seen examples like – Lure I think is a common usage. And I think – Pete, correct me if I’m wrong – I think you guys were working on a JavaScript engine-based backend for iOS and Android apps. Is that still a thing?

Yeah, that’s still a thing. We ended up open sourcing it; it was called Calatrava. That’s basically trying to take advantage of that idea of, if you want that native look and feel, don’t spend a bunch of time trying to make HTML look native. Embrace that native look and feel and build native UIs, but the user doesn’t care whether your business logic and your API communication layer and all the rest of it is implemented in JavaScript or Objective-C. JavaScript is fast enough for that stuff anyway, so that’s what we were doing with Calatrava, so just use JavaScript for the stuff that’s shared across platforms.

The thing that was really interesting with that though is we made it so that you can start with a web technology for the frontend, for the face, and then upgrade to native for each screen. With the idea being – I think, exactly like you say, Chris, the hub part is figuring out the interaction design and figuring out how the screens are going to flow together and all that kind of stuff. For some teams – I’d say quite a lot of teams – they can do that faster with web technologies. They can experiment with user interfaces faster with HTML and CSS than they can with Android or iOS native.

The original intention was, we’ll build it so that you can have a cheap prototype built in HTML and CSS, and then you can upgrade each of those phases to native. What we were also quite surprise at is how often you don’t need to do that – how often the users can’t really tell, whether it’s being laid out and rendered in HTML or iOS. I think the big thing where you do see differences is around animation and scrolling and things like that, but if the animation scrolling is done natively and the bit inside is HTML, a lot of times you can get away with it.

Yeah, that’s really interesting. I think that’s true definitely of – and there’s a few pages in our apps that are essentially are just rendered HTML from the backend and I think that’s definitely worthwhile. You don’t need to make everything native, but I think it’s a false economy to think that you could build an entire app cross-platform.

I think one of the other interesting things about that is, I’ve noticed particularly with mobile development that there seems to be an increasing amount of specialization amongst developers. There are definitely people – and it’s probably slightly more true of the iOS developers because historically, Objective-C has had quite a big barrier to entry, just because it’s such a different language to the other languages that we’ve grown up with, I guess.

And so you see a lot more specialization, particularly here in the Valley. There’s definitely iOS developers who do nothing else, and there’s definitely an increasing number of people who are just Android developers and don’t know iOS. I think that’s something that I would like to see blur a lot more over time. I think there’s huge benefits to understanding both the platforms and being conversant at least in the way that the different platforms work and are developed.

When I switched from iOS development to Android development on Band of the Day, I actually took the plunge, got a Nexus Android device and used it exclusively because I wanted to understand how the platform felt as a user. I continually come back to that experience; I still use an Android phone because I’m still developing on Android, although I do also have Apple devices, obviously. There are often design decisions that we have to make, and interaction design decisions in particular that make perfect sense on iOS, but are actually very alien on the Android platform.

Obvious example of that is the up button versus the back button. The up button – strangely named, I know – is what you have on the navigation controller; the back button on the navigation controller. On an Android, you’ll see it on the top left as well, but it has a slightly different behavior. It goes up the hierarchy of screens.

There is another button called the back button, which is like a back button for a web browser that goes to the last place you came from. They have quite subtly different behaviors, and if you haven’t actually lived with an Android device, you’ll probably do something that feels very alien to a native Android user as you implement those particular buttons. I think living with a device is actually important when you’re developing on that platform.

So that leads me to ask a question and that is, generally, we have this idea that we want an iPhone app and then an Android app, and we want them to do the same things or provide the same functions. How much of the logic do you then push into the app versus maybe managing over the API, where you have shared functionality and you can have it done the same way, both sides?

That’s a good question. I’ll give you a concrete example of somewhere where we initially got it wrong and where we’re actually slightly fixing it. We actually have three different versions of Applauze now – we have the iOS version, we have the Android version and we have an HTML5 version where you can actually buy tickets for pre-sales, band shows and things like that. All three of our platforms reimplement the shopping cart functionality so that we don’t have a backend shopping cart concept in the API. Currently, each of those three different platforms have their own implementation of fetching all the things you need to go through the purchase flow and build up your order, and then sending the order out at the end.

That has led to a fair amount of duplication of code, and so what we’ve started to do now initially on iOS and then we’ll move it on to the other platforms. We used to build a backend abstraction for that where we build up incrementally the order on the backend and take a lot of the logic that was on the client and move it into the API.

I think that’s a fairly common pattern. It’s actually kind of tricky, in mobile apps in particular, because your versions are going to last longer. It’s very different from doing web development, where if you have a new abstraction on the backend, you can just immediately replace all of your frontend implementations with that new abstraction.

On mobile, you have to build a new abstraction, and then wait a couple of months for everyone to upgrade their devices and then retire the other one, if you ever get to retire at all. We’re in the process of doing that, and I think that that’s something that you have to think about on mobile differently from the way that you think about it in, for example, web development. It’s actually interesting; I think of that as refactoring. I think of that as refactoring across app boundaries, but it’s still refactoring. To me, it’s still a case of “Okay, we’ve got an abstraction here that works; let’s move it to a place where it can be reused.” I think you have to continually be thinking about that.

One of the other things we’re looking at – we currently use a hand-rolled JSON as our communication mechanism on our APIs. I’m interested in investigating something like protocol buffers, because that allows us to generate a lot of the API code, which does give us some reusability across the different platforms, more so than we have in JSON. It also gives us some other nice things like schema support, for example, so we know that we’re calling the same thing as the same thing on different platforms. So that’s part of the answer.

I think that’s part of the answer to the question you asked.

Yeah, kind of. It seems like some things make sense to duplicate across the different platforms when the functionality, the interface, is going to change from one to the other – is the impression I’m getting from you. I guess my question is, when do you make the decision to push something down to the API versus pull it up? Because there’s not just the tradeoff of “Hey, the interface on Android is a little different,” but there’s also the tradeoff of “It takes time to go talk over the Internet to the API to get the information that I want.”

Yeah. What we do is we try not to be developing the same thing on multiple platforms at the same time. We have this kind of leapfrog approach where, if we have a new feature, we will pick one of the platforms and develop it there. Once we’ve proved out the API and the interaction, then we’ll pull up that to the other platforms.

It’s not that iOS comes first these days, or Android comes first – it’s just whoever has more scope at the moment, depending on what they’re working on and what’s coming up in the future versions.

That’s useful because, again, coming back to what we were talking about before, the hardest thing isn’t actually developing, isn’t actually writing code, isn’t actually cracking out the UI. The hardest thing is getting the interaction design right. Let’s do that first on one platform, and then once we’ve learned what works, we’ll move that onto the other platforms.

That’s a really interesting strategy. I’ve never heard of teams doing that before, but it actually seems like a pretty smart way of doing it rather than trying to figure it out in two different places at the same time.

Yeah, I think it’s really important. Actually, if you have the scope for it, it can let you do more than one thing at once as well. Android could be investigating a new seating chart – we have an interactive seating chart – so Android might be investigating that, while iOS is doing another feature, maybe an enhancement to chat or to sharing or something like that. It allows us to kind of concentrate on one thing at a time.

Do you ever build things on one platform and then realize that they weren't a super great idea or that they weren't something that’s needed on the other platform and just leave them just on the one platform?

Absolutely all the time [chuckling]. In fact, that’s one of the reasons why both Band of the Day and Applauze on Android have taken less time to deliver because there’s parts of the original apps that we did on iOS that we realized are rarely used and are probably not necessary to bring onto the new platform.

Some of that are fundamental differences, like the way that sharing works on iOS versus Android in Applauze is interesting. We use standard system share button on Android rather than trying to develop our own kind of friend pickers and things like we have on the iOS device. Part of that is technical because on Android, you tend to have a larger variety of ways of sharing, like many different SMS apps, many different mail programs, so you can’t pick one and then say, “Okay, everyone’s going to share using this.” So you have to be a bit more democratic, I guess, when you do those sort of features.

Do you ever get bad reviews or people complaining? The wife has an iPhone and she has features that they don’t get on their Android device [inaudible 29:16].

We’ve actually been very lucky in most of the feedback we get about not being on one platform or the other is just “Please be there because we want you to be there,” which is actually really nice. When we were just on iOS – always one of my favorite things – we had someone who was using Band of the Day on his iPhone and when he got his Android, he kept his iPhone around just on WiFi so he could use Band of the Day. He was already happy we did the Android version. It’s always nice when someone loves your app that much.

Wow. I thought you were going to say you had someone who reverse-engineered your API and built the Android app for you [chuckling]. I actually worked at a company where someone did that.

[Chuckles] Interesting.

It was truly pretty amazing. It was a large bank and they weren't very happy about the fact that someone was using their API totally unofficially, but that happened because they didn’t like the Android app so they built a better version themselves.

That’s really funny.

Tell us something, Chris, that I guess the diversity – if you going to be generous to diversity, if you’re going to bemean the fragmentation in the Android world, and people talk about this a lot. It’s one of those things, going back to the start of the conversation you said there tends to be an adversarial relationship and one of the things that iOS developers like to say about Android development is “Oh, this fragmentation and you have support – all these different operating systems and screen sizes and all the rest of it.” Having spent time on both platforms, what’s your take on how real is that?

It’s definitely real, and it’s real in ways that you don’t expect. The one that everyone always mentions is screen size, but screen size is not a big problem with Android because the tools have always supported awful screen sizes, and so layouts have always been easy to support different screen sizes.

But what is interesting is that many vendors actually customize Android quite extensively. You can have bugs that are very hard to find and are caused by vendor customization that you would never guess even exist example:

we have a drop down menu in Band of the Day, and we are very strong on design, so everything has its own custom font. In Android, you can use an attributed string essentially. Instead of setting a string, you set a string with a font into a control. And we had a crash on a live version of Band of the Day from someone tapping on that pull-down menu. What was happening was, one vendor had patched Android to log the name of the menu item that was selected, and the menu item was actually returning a spannable string – not a string. They were casting something that wasn’t a string back to a string, and it caused the app to crash, and there’s no way you could guess that, because that was a customization that they had done for that particular device, that particular vendor.

That’s a rare case, but there are definitely cases like that, or there have been in the past, where you will not have a service that you expect to be there, or the entire UI will be skinned differently so all of the standard colors are different, so your app looks really strange. You basically have to override every single system tower if you’re not using the standard-themed colors on Android, which can be a pain.

I just want to touch really briefly. I had an Android phone for a long time, and what you’re talking about with the customizations either by the carrier or by the vendor – those kinds of things drove me crazy.

The other issue was that a new version of Android would come out, and I couldn’t get it for a year, a year and a half, and all of the new apps were using the new version.

Yeah, that’s absolutely true. It’s interesting – people talk about Android as being an open platform and iOS as being a closed platform. For the end user, it’s actually the other way around. For the end user, Android is much more closed because I can’t upgrade my phone; I can’t put the new version on the day it’s released like I can on iOS; I can’t install anything on my phone in some places. There are certain places and vendors and carriers who customize the phones and won’t let you use the Google Play Store. The Kindle has its own play store, has its own apps store.

From a user’s point of view, it’s much more closed than iOS. The genius of Apple was to release a product that was so compelling that carriers felt that they had to have it even though they had to see the responsibility for what gets installed on the phone.

People tend to forget that before the iPhone, that was unheard of – the idea that you would be able to install what you wanted on your phone was impossible. On Android, it often still is. Android, the platform and Google, the company who leaks the platform, are moving to change that as much as they can. They moved many more of the services in recent versions of Android into what they call Google Play Services, which can be updated the same way any other app can be updated on the phone, which means that quite extensive changes to the platform can be rolled out incrementally, even if the carrier is refusing to do a major number update on the phone. Android does have backwardly-compatible SDK, although it’s somewhat awkward to use.

Android is developed in Java, but it’s a very strange breed of Java. It feels a lot like the kind of Java that was written by C programmers, which it probably was because that’s the nature of embedded design – you’ve got to build something that’s efficient, so you use static variables everywhere or magi numbers, and you pass around HashMaps essentially and things like that.

It’s definitely an issue, but it’s not an issue in terms of screen size. It’s not an issue in terms of which SDKs you use; it tends to be more in terms of what the carriers have customized and whether you can actually use certain services. For example, Google Maps may not be installed, so you may not have access to a map SDK. You have to show a button that says, “Please install this external service if you want to use the map” sort of thing, which of course is rare on iOS because you’ve always got the Apple map SDK or whatever.

So given that there are all these different options, all these different devices, operating systems and different flavors of Android, what are some techniques to kind of manage this complexity?

Good question. I think the general rule of thumb is to have as many devices as you can buy [chuckling] and to test it on different devices from different vendors – particularly Samsung. They have a very customized version of Android, so it’s important to test your device on a Samsung device because the UI will look completely different.

The other thing is there are tools out there – I think Testdroid is one, but there’s a bunch of vendors who have basically racks of patched devices where you can send up an automated test using Robotium and run it across multiple devices and see what the screenshots look like and see if you’re getting weird crashes.

We’ve done a little bit of that; we didn’t do a lot. We found that actually manual testing and a limited amount of automated testing is actually sufficient in most cases. We also have for our Android, we’ve targeted version 16+, which is 4.0/4.3 I think, and that is the point at which much of that fragmentation was addressed by the SDK. Devices that are newer than that version are actually much easier to target than if you’re targeting earlier versions of Android. We made a conscious decision to do that, and it’s turn out to be the right decision, I think.

You do have to go further back in time on Android than you do on iOS. It’s well-known that iOS users update their phones much more quickly than Android users, so that’s something that you have to bear in mind when you’re developing on Android.

How reusable are design patterns that you’re using. You start, you do a fast-follower – or you call it leapfrog approach – where you work out one feature, say, in iOS. Now if you’re working with one designer, how much of their design assets are being reused?

I would say the feel of the design is used more than the assets of the design. Nowadays, iOS is much flatter than it used to be, but it still has a different kind of design aesthetic to Android. Interestingly – and this comes back to fragmentation, I think – Android, the new material designs that have come out of Google emphasize a lot of flat textures and a lot of very simple shapes, like the buttons are round shapes; very few actual image assets.

I think that’s partly because there’s so much fragmentation in terms of screen DPIs and so forth, that you can’t do what you do on iOS where you ship an image and then an @2x. There’s actually HDPI, MDPI, XDPI, XXDPI and XXX – so you’d have to do six different assets to do the equivalent thing on Android.

Many of the new designs like material design are designed to be programmatically generated rather than image-like .pngs and compositing and stuff like that. I think that’s part of an answer to that question. The feel, the interaction design can be reused, but generally the assets are unique to each platform.

I’m interested to hear about the APIs. You talked about Android feeling like it was Java written by C developers. One of my favorite things about iOS as a platform is the quality of the APIs, specifically the consistency of the APIs and the design patterns that are very consistently embodied and their very small set of patterns that are applied in lots of different places. Compare and contrast that versus Android. Is Android really bad, or is it not that bad?

That’s another good question. I think I 100% agree with you on iOS and the iOS platform and the APIs. When you think about what Objective-C is and what Cocoa is, it has existed – it’s actually older than –. The Next system, which of course was the origin of Cocoa, was out before Windows 94. When you’re looking at NSString – your next step string – that’s an object that’s been in the wild for – what is it now, 20, 30 years? And it shows in the depth of the platform and the history of the platform and the very strong aesthetic in the APIs.

It’s also interesting to think of that in terms of the way that engineering works at Apple. If you’re developing QuickTime, or if you’re developing something on Mac OSX, you are using the same tools, you are using the same design patterns, you’re using the same aesthetic in your APIs that someone who’s developing the APIs for iOS are using. I think having everyone in the organization, engineering-wise, pulling in the same direction really shows in the quality of the APIs and the quality of the tools.

One of the things that's been stinging me this week was performance testing on Android, and it’s very, very rudimentary compared to the kind of powerful tools that you have on iOS. The problem with Android is that Java was a choice that was made, I think, for familiarity reasons and for pragmatic reasons, but one that I think is starting to bite on Android development. There was a prominent case of Oracle suing Google for reusing Java in ways that they felt were unfair or against the Java language. The version of Java that you can use on Android is still Java 7.0 – you can’t use any of the nice Java 8.0 Clojure APIs and streaming APIs and things like that.

The brand of Java that’s used, like I said, is a very different-based – the sort of feel of the APIs on other java projects. There’s lots of passing around of HashMaps and building – or they’re called bundles, but they’re essentially HashMaps. There’s lots of magic numbers; there’s no real use of –.

One of the things that I think is most interesting in terms of design patterns, dated back to Joshua Bloch’s Effective Java book, is the strongly typed enumeration pattern, which is now part of Java syntax. But it’s not used on any of the Android APIs; it’s all just magic numbers. You have to remember which constant is appropriate for which API – although it’s Java, or it’s a very different type of Java to one that you would’ve used on another platform

And I think that the fact that the Java VM is not the same down to the middle as Objective-C and Cocoa are on iOS and Mac OSX, it’s actually kind of a problem because it means that if Android wants to get more efficient, if they want to get rid of garbage collection, for example, and use something like Arc, or if they want to do really sophisticated compiler-type tricks like Apple are doing now with Swift, which is fantastic, they have to move off the JVM. And if they move off the JVM, then where do they go? There’s the NDK, but that has none of the UI components that are purely Java at the moment.

Do you need some kind of layer to wrap the two together? There’s kind of a bind there when you think about where could Android, the platform, go in terms of development over the years. It’s an interesting question; I think it’s going to be very interesting to see what the answer might be.

I would love to see, for example, a version of Google’s Go language that was targeted to Android. There have been some open source attempts at doing something like that. Or maybe a high-level language that still build on the JVM, like Clojure for example, and there's an attempt of that as well. The choice of the JVM is great in a pragmatic sense, but in terms of evolving the platform, it’s fairly constraining, I think, in a way that is very different from what Apple are able to do with iOS.

It’s pretty funny because I think a few years ago, we could’ve had the same exact same conversation, but the other way around where Objective-C is this dead language that they can’t move anywhere and no one wants to learn it, so people only know Java and it’s so easy to get started with Android. It’s clear and undeniable that Android will win because of the platform they chose, but the argument you’re making is pretty legit in the other way. Particularly now that you have Swift, which for its fault and its early age is still a very, very much – in my mind – a lot more attractive than programming in Java or on a virtual machine.

Yeah. It’s worth mentioning that our iOS team is actually using Swift to roll in new functionality. The fact that you can do that is actually pretty impressive as well that you can say that the new functionality is going to be in Swift, and it’s going to inter-operate with our Objective-C code and so forth and so on.

I think what Apple has done and what the LLDB team has done with Swift and with the APIs and the language and the whole kind of infrastructure of iOS is just fantastic. When you look at things like – even Arc, Arc is a great example of really amazing, powerful innovation at Apple that just bucks the trend of the rest of the industry. Everyone was expecting garbage collection on iOS, and they said, “Well, garbage collection doesn’t actually work that well on embedded devices, so we’re going to invent something else and we’re going to have a really smart compiler,” and it’s fantastic.

It’s really good.

Yeah, we worked out so well they took garbage collection out of the desktop as well [chuckles].

Yeah, yeah.

So I have one more question and that is, let’s say that – and this comes directly out of –. You said that with Applauze, for a long time, you were kind of the only mobile developer. If I have an app that I want to build and I want it to be on both platforms, am I better off to build the MVP with one and then build the MVP with the other? Or should I consider, on the other hand, building them in lockstep?

I would say the pragmatic choice is to choose the one that you’re best at. If you’re an iOS developer, obviously choose iOS. If you’re someone who has an Android phone and has done Java in the past or whatever, choose Android. The most important thing is to learn how your users are using your app and learn what you actually want to build – that’s the hard thing. If you’re going to spend a lot of time learning a new platform or whatever, then that’s just going to be a waste of your time.

I think, back to what Pete said before, if you’re a web developer, do it in HTML5. Do an HTML5 app and then once you’ve worked out what you want to build, it’s much easier to go onto a mobile platform and build it there. Honestly, I think that development on any platform is the easiest part of what we do; the design is the hard part.

One quick addendum to that question. For a long time, people are trying to get an approach for building one or the other, and what I’ve always experienced is that iOS development has gone quicker. It’s kind of a framework that’s a little more polished and there’s less screen sizes to handle for, so people that have done both apps have said that the Android has taken longer, is more expensive. Do you still see that being the case?

I don’t think that's necessarily true. When I hear that, the first question I ask is, “Is that person an iOS developer?” and almost always, it is true that they are an iOS developer who’s then moved on to doing Android.

I don’t think either platform is inherently harder to develop for. There are definitely tradeoffs, and there are definitely differences in development, so I think that choosing the one you’re most familiar with is the first step. Once you know what you want to build, I don’t think moving on to another platform is necessarily harder. It may be harder if your team is an iOS-centric team and they’re trying to pick up a new platform. Our Android developers are Android developers, and that’s what they do and that’s what they’re good at and that’s what they love, and I think that shows in the way they do they work and the way the apps turn out.

Alright, well should we get to some picks? Jaim, do you want to start us off with the picks?

Sure. I’m going to have one pick. If you know anything about me, you know I like spicy food. I like hot sauce, and I tend to use hot sauce like salsa; I put it right on chips, which is kind of crazy, but that’s how I do it [chuckling].

How hot?

As hot as it goes. I don’t know; I’ve never tried the ghost pepper, but habanero is fine – not that I even eat habaneros by themselves. I found, over the past month or two, a really awesome hot sauce, which I think is fairly available. I think Whole Foods has it; they’ve got it at the local coops, but The Boulder Hot Sauce Company has a couple of really good hot sauces. They’ve got a Habanero and a Serrano-based one, and they’re excellent hot sauces. If you like spicy food and you’re tired of Tabasco, check it out The Boulder Hot Sauce Company. Good stuff.

Very nice. Pete, what are your picks?

I have one topical pick, which will be slightly less topical by the time this is aired, but that's okay. .NET just got open sourced – that’s pretty cool. So I’m going to pick a tweet from 2009 where a .NET MVP asked @scottgu to open source .Net and apparently just got blank stares from everyone in the room. Five years later, he obviously managed to persuade them. So congratulations to .NET!

And I think it’s actually pretty exciting for us as mobile developers, because it means things like Xamarin may become more interesting because we can actually use VisualStudio on our Macs so we can compile .NET on our Macs rather than having to keep a crappy, old Windows PC lying around. Sorry Windows, I don’t like you [chuckling].

Pick number two, the UK Government Service Design Manual. This is not something I would expect any government to have produced; it’s actually a fairly sane document on how to build software in a modern way. It talks about things like getting really fast feedback from your users, releasing early MVPs and all that kind of stuff. It talks a lot about the right way to do Agile, and it’s from a government agency and I would not have expected it.

It’s actually really good; it’s a really good, well-collected set of materials around how to build software in a user-oriented way, which I think is the way to be successful.

My last pick is a beer. I got to go to Washington, D.C. for the first time this weekend – last weekend – and a beer that I was enjoying in that region was Loose Cannon, an IPA from Heavy Seas Brewery. It tastes like a West Coast IPA – pretty solid. Nice, sticky, lots of hops, lots of mouthfeel, very drinkable. If you can get a hold of it, you should do so. Those are my picks.

Nice. I’m going to just quickly pick some of the things that I’d been using to pull together this website for JS Remote Conf. The first one is AngularJS, which is really awesome. It has a plugin called ngAnimate, which allows you to do things like when you submit the contact form, it actually does the submission and then allows you to change which part of the page is showing so that it says, “Your message has been sent, click here to send another” kind of thing.

And then I used 99Designs to get the design done, which is also very awesome and nice. I think that’s all that I really got there, so I will throw the horn over to Chris. Chris, what are your picks?

Just while we’re talking about picks, Pete Hodgson’s pick for government.uk is actually really good. What they’re doing over there is really interesting, trying to change the way that software development is done by governments, and the sort of things they’re doing over there is really exciting and points the way forward for the many governments [inaudible 51:25].

I would say, since this is an iOS-centric world, I would pick – if you haven’t tried it out, try out AppCode, which is from JetBrains. An absolutely fantastic IDE; I know everyone uses Xcode and it won’t get rid of Xcode for you, but if you want to be refactoring and if you want to be able to change your code in very flexible ways, there’s nothing better than the JetBrain’s IDEs.

Their community access version of IntelliJ is the Java version of their IDE, but their community edition is the foundation of the Android – the new Android development platform, and it’s fantastic, and their AppCode is a fantastic IDE for iOS developers. They have an EAP, an early access version, out now, just free to try, which has early support for Swift, including some Swift refactoring, which is really awesome.

The New Science of Evo Devo by Sean Carroll – it discusses the way the genome works. For developers, it’s really interesting because it goes into quite a lot of depth about the way the genome actually programs our bodies and the way that genes are actually activated and switched on and off and things like that. I found my developer brain part’s kind of really stimulated by reading that book; it’s a great book. A fantastic book.

Do I want to do a third one? Let me do a third one. An article I read recently that I found really interesting was The Hypercard Legacy, which is about the software tool – well, it’s about Hypercard, which was part of the original Macintosh way back in the day. It was one of the first times I ever saw any kind of hypertextual linking between different things. It also had a really interesting and quite quirky programming language behind-the-scenes, and it kind of bridged the gap between what we do as professional developers and what people used to do in things like Hypercard – or around the same time, things like VisualBasic, God help us. There seems to be a gap at the moment for the amateur developer, someone who just wants to do something simple to help make their day-to-day life better, and I think that’s a gap that needs filling, because we can’t solve all the problems. There’s a gap in the market there for what used to be filled by things like Hypercard – a fantastic tool, fantastic ideas behind it and something that I think is worth reading about and thinking about.

Awesome! Alright, well I don’t think we have any announcements, so we’ll go ahead and wrap up the show. Thanks for coming, Chris. It was a fascinating discussion, and hopefully we can get you back on another show for maybe another topic. How do people get a hold of you if they want to find out what you’re up to these days?

The best way would be to look on my Twitter account, which is @chris_stevenson – S-T-E-V-E-NS-O-N. I did have a blog, but it died a couple of years ago with my domains, so I’m trying to resurrect that as we speak.

We should resurrect your blog [chuckling]

+1! Especially now where you’re – I think, with your position, you’re in a place where you kind of have to experiment with things that are outside of your comfort zone. I mean, even now that you still have a team, you’re kind of forced to that as a CTO, so it’d be really interesting to see what you’re discovering and what you’re finding, as well as what your team is finding as you explore these different areas of business and technology.

Thanks. Yeah, I will try and get it back [chuckles].

Alright, well thanks for everyone for listening. We’ll catch you all next week!