Facebook recently hosted its first-ever Mobile @ Scale conference at its hacker headquarters. The conference assembled senior engineers and directors from Twitter, Facebook, Pinterest, Dropbox and LinkedIn into a rather small room to discuss common issues faced by mobile engineering teams. Access to information was impressive and the transparency was refreshing. I was very excited to be a part the crew invited to attend.

Below, I’ll cover what I felt were the high level themes, and some of the more interesting bits, from the jam packed day of talks. I’ll later publish a podcast I recorded which covers the content in more detail!

Silo Problem Solving.
The Facebook VP of Engineering, Cory Ondrejka, was first to point out that we’re all facing and solving similar problems in mobile, it being such a fresh, and fast changing area of tech. The issue is that we’re problem-solving in...

From a product development perspective, it’s been incredibly fun to watch the slow, but steady, evolution of the Apple TV. Reworking the UI, adding bluetooth keyboard support, content additions, and AirPlay among other enhancements. Although still considered a “hobby” according to Tim Cook, I have found his language in support of the product has been getting stronger in recent quarters (I listen to every earnings call). I think Apple knows there is something there, thanks to the millions of units flying off the shelves, but I’m betting the content access continues to be the uncontrolled dependency that blocks the Apple TV from becoming a more central product. While we wait for the next iteration, hoping for something big, I hear nothing but love from the people who choose to drop $120 on this little black box. Probably the most value for dollar you can extract from the...

If you you don’t follow the reference in the title of this post, you’re probably not alone. In fact, I would bet big money that very few people make it a practice to add web sites to their iPhone’s homescreen.

This is one of those rather esoteric iOS features that are often cited by those who adamantly defend web apps as being on equal footing to native apps, but rarely used by those customers that we’re all trying to please, equally. The idea is that a web site can “easily” be added to the Home Screen, just like any native app.

All you have to do is:

1. Open Safari on an iOS device
2. Navigate to mobile-friendly website
3. Click the Share Action button in Safari, and select “Add to Home Screen”.

Easy. Right?

I think it’s easy to say the words “add to home screen”. It’s also easy to say that users will love doing this, and will thank you for not forcing them to download an app from the...

This is an absolutely fantastic inside look at how Facebook builds their iOS app, and the path they took from web to native. I have summarized some of the standout info, but encourage everyone who’s interested in native iOS development to watch the entire talk.

Facebook for iOS was originally created by a single developer. Later, they converted to a web app, using HTML5 and javascript in a native wrapper, a hybrid solution:

Facebook was growing really fast… [the] web was in our DNA, so we decided to use HTML5 and javascript in a native wrapper.

• they developed a bridge between native and web; significant investment
• developed a way of placing web and native components together on one view; this wasn’t easy
  • benefits to hybrid: instant products updates (no app store review), made A/B testing really simple (data guides them on feature decisions), and got them to a single codebase.
• ...

What follows is by no means a novel approach to building web apps. It just happens to be the way which I believe allows us to build them in a manner that’s fast, flexible for the future, and mobile app {native or web} friendly.

I’m oversimplifying intentionally, but I see two architectural components for modern web applications: UI Layer and a REST API. Nothing more. The technologies used to build each piece are really up for debate, but the UI will likely be mostly Javascript (I suppose you could use Dart ;)), and the API will be composed of some reasonable backend technology (Java, PHP, Python… whatever works for your team).

This approach is similar to that used on Twitter.com, as described here on their engineering blog, though I think they’ve tweaked it since the time of this post:

One of the most important architectural changes is that Twitter.com is now a client of our own API...

An important part of the customer experience with software is how and when software updates are delivered. In days of old, we’d wait patiently for years while Microsoft toiled in isolation on their latest and greatest creation. Today, however, people are delivered updates in software on a more continuous basis.

At Apple, the operating systems update each year. At Facebook, new updates are delivered once per day. At Etsy, though it may not be obvious, updates are delivered sometimes 50 times per day! The speed of improvement is astounding, but it leaves me wondering, “how do they do it?” I explored this question a little and here’s what I found.

Facebook

The following is taken from a talk given by Chuck Rossi, lead of the Facebook Release Engineering team. With a release engineering team of only 3, it’s no surprise that they have invested heavily in tooling. Also interesting, Mark and...

More and more, I’m noticing that automation testing is a key skill set for the modern Quality Engineer. More companies are looking to automation as a way to allow a few people to be incredibly productive. Although people often think of automation testing for front end web applications, there is also a lot of recent attention on adopting the same techniques for iOS native apps.

Here is a very high level list of tools and skills one should adopt when building out a great automation practice.

Tools

• iOS UI Automation framework. I have reviewed a number of test automation products, and found that the UI Automation toolkit from Apple provides great flexibility, with ease of test authoring. Also, because its the Apple recommended solution, I believe it will serve you well as the iOS platform evolves (i.e. it will likely improve). The only drawback to this solution is that it only supports...

http://mobile.theverge.com/2013/2/11/3976734/nike-not-working-on-fuelband-android-app

Right now, we’re focused on iOS and the web

I think this hits upon a continuing trend. If your app is targeting up market North Americans, then you’ll be looking to an iOS-first mobile strategy if you want to maximize share and minimize development costs. If you’re more concerned with maximizing share, then adding mobile web support is a great way to cover off Android and the slightly long tail of other mobile platforms with a single development effort (assuming native features aren’t a requirement). Nike is not alone in adopting this strategy. Although worldwide Android marketshare numbers continue to impress, I think it’s primarily the usage numbers which drive a decision like this.

In other words, the share of people using devices for connected activities, favors iOS, so that’s where app...

After teaching myself iOS development in 2008, and Android development a few years later, I quickly learned the value in a well-supported development platform. One that’s curated and carefully maintained by a single entity; Apple and Google, in my case. These platforms allow me to be very productive.

The issue I see when delving into the world of the web is that a central web platform doesn’t really exist. I can’t ask the question, “I want to build a mind-blowing web application today, what framework should I use?”, and expect to get a straight answer. In some respects, the plethora of choice this problem represents is the power of the web, but overall I think it does the web a disservice because there isn’t enough weight put behind a single platform.

I might choose today to get involved with backbone.js, only to find out that tomorrow, it’s the Play framework, or Angular.js, which is...

APIs are to developers what a great interface is to an end user. Like curb appeal for a house, these APIs should be beautiful and represent the rest of what you’ve built. So why don’t we focus as much on creating beautiful Developer Interfaces (DI) as we do on User Interfaces (UI)?

Most of the points I’ll make here focus on REST APIs, but could easily extend to an Interface in Java, or a .h file in Objective-C. In all APIs, much of our time should be spent agreeing on, polishing, and simplifying our interfaces before we publish them to the end customers; in the case of REST APIs, these end customers are other developers. 

Here are the high-level bits which contribute to a great API:

• Consistency. Not everyone agrees on how a great REST should look (see pragmatic versus pure REST), but I think everyone can agree that being consistent within your own API is of paramount importance. If...