Of course, this will not be for everybody. With the new Chat Heads, Facebook is clearly trying to keep other competing messaging services like WhatsApp, MessageMe and SnapChat at bay. These services are mostly used by teens. Getting status updates on your home screen and even your lock screen has a huge impact on privacy and more serious business oriented users will not like this. Also, out of the box only 5 phones will be supported (HTC One, HTC One X/X+, HTC First, Samsung Galaxy S III, Samsung Galaxy S 4, and Samsung Galaxy Note II). This is probably because of hardware/OS requirements but also rigorous testing required to make sure all works fine. A crashing home screen of course needs to work flawless, otherwise users will uninstall within minutes. Your Android phone will become dominated by Facebook, and not everybody will like that. Hopefully Facebook keeps it as user experience focussed as possible and will not become the new toolbar as on the Windows platform.

So what does is mean for other companies? Google will be less visible within Android with Home, no search anymore on the home screen. No support announced for the Nexus 4 was remarkable, but as Facebook Home will be downloadable via Google Play store Google is aware and letting Facebook put it out there. Still users need to sign up with Google for a Google account, and Google can still gather all information it does normally. In the future FB might include it’s investor Microsoft’s Bing search engine and Bing Maps. Android has not been altered for this, although HTC admitted that they made some chances to Android to allow notifications to be shown in a more prominent way. For Apple, this means that the number one consumer service world wide will have a better presence on a competing platform, because of Apple’s own choices. Apple chooses to remain closed, keeping control over apps in a strict way. Yes that means less malware and crap apps, but also stops 3rd party developers from pushing the platform further. As we move to more constant monitoring and more push from apps from the current situation where interaction with your mobile phone is initiated by the user, background processing will prove to be vital. Apple not allowing this will be a big hurdle for companies to innovate on iOS.

I am curious to see what is does for app distribution. Facebook Home also has an app launcher, which is remarkable because the Android app launcher itself is great and Facebook for now does not all a lot of value. The value it has right now is that it is integral part of Facebook Home so you don’t need to switch a few taps forward to the Android launcher. This FB launcher offers great possibilities for the future, making FB a prime app marketing channel.

I am really excited about the new functionalities and interaction patterns, Facebook is pushing the envelope with what is possible for mobile. What do you think? Will you install Facebook Home on your Android phone?

Also look at the Mobtest Renaissance Github repository, where various documents about testing and background information is provided.

Native technology allows for excellent apps, whereas HTML5 apps will be at best just OK

Just look at the top 25′s of any category in the Apple iTunes store or the Google Play store. Most if not all apps are built using native technology. Yes, you can build crappy apps with native also, that is not hard thing to do. Excellent HTML developers can get pretty close to native with their hybrid apps, look at the LinkedIn iOS app. But still, you can see the interface is not as fast and snappy as for instance Path or the new Facebook iOS app. Fact is, users now know you can build excellent apps for mobile so will expect this from any app.

Cross platform is a means, not a goal

As software developers, our goal is to create the best apps that reach as many people as possible, with the least amount of development effort. By definition, there is a tradeoff: by choosing HTML5 that has the promise of cross platform development you will limit yourself profoundly. No smooth animations. Difficult if any access to system level API’s and hardware. No extensive control over threads, and I can go on. Sometimes I talk to developers and I get the feeling that for them cross platform is a goal by itself, to the point that it becomes a cross platform fetishism. Cross platform is a means, not a goal. No user cares about what technology is used, it is about the end result.

Write once deploy everywhere is a myth for mobile

Mobile browsers differ quite a bit. The standard browsers that shipped with pre 3.0 (Honeycomb) Android are notoriously slow and bad. So trying to serve all browsers with the same HTML technology will be hard, and even frameworks like Sencha and jQueryMobile will not help a 100 % with that. Furthermore, iOS, Android and also Blackberry and Windows Phone have different user interface standards. Users on each particular platform will notice if you serve exactly the same app for all. So even using HTML5, you will build multiple versions for different platforms and platform versions.

It is effectively a duopoly for iOS and Android

Android and iOS dominate the mobile ecosystem, taking as much as 80 % of mobile usage . You can forget for now about Blackberry or Windows Phone, so instead of one mobile web app you have to create only 2 native apps. OK 4 maybe, customizing both for phone and tablet devices, but you would have to do the same for your mobile web app.

Native is not that hard

Yes both Objective-C (iOS) and Java (Android) are strongly typed messages object-oriented languages and that might seem scary at first for web developers. In the days of the iPhone 3 I spent a couple of months cursing at Objective-C, it strange syntax and the fact that the few books about iOS development were mediocre because of Apple’s insane NDA but I managed. Nowadays iOS and Android have matured a lot, meaning that the tools are great, libraries are excellent and there is a lot of knowledge and learning material out there. iOS has ARC now so you don’t have to worry about memory management anymore.

Web developers, don’t be lazy, and pick up
a native language

Mobile Internet usage is growing like crazy, and already more smartphones are sold than computers. Mobile is where the future is. A lot of effort is put into HTML for mobile, but it will be years for it is up to par with native. Yes it is easier to use technologies that you are familiar with, but not always will you get the best results. So you as a web developer shouldn’t be lazy: get a web developer buddy, pick a straw each and start learning either iOS or Android development. Your users will be much happier with your apps, which will mean more money in the bank for you.

Fast 3d maps but no offline access

The maps, including 3D versions are fast! OpenGL is used, and runs pretty fast on my now ancient iPhone 4. They even support iPhone 3Gs with iOS 5.1, so they really did a terrific job on optimizing speed. Apple Maps for iOS requires an iPhone 4S for 3D views, also satellite 3D views. Offline access would be great to have when you drive through areas with no cell phone reception. No iPad version as well, no voice input.

No Facebook style left top menu button, but swipe from right

While the app has the design from the new Gmail for iOS, it does not share the Facebook style left top menu button to slide out  the menu, like Gmail for iOS and also the Youtube app for iOS has. Instead of that, there is the subtle minitab to the right hand bottom that indicates you can swipe in the menu from the right. Interesting.

UIWebWiew for login, allowing two factor authentication

Authentication is always a hard thing to do right in native apps. Nowadays you don’t want to prompt users for usernames and passwords, but use techniques like oAuth to take users to your own web site and let them login and authorize the app access there. All very hard to do natively, in particular when you support two factor authentication. When you set two factor authentication up, you will receive a text message on your cell phone with a code that you enter after login. Like the Youtube app, Google uses a UIWebview to show you a web page to login, and this allows them also to suppor the two factor extra code dialog.

Shake to send feedback

Very original and well thought. When human beings are frustrated they have the tendency to want to break things, become physical and move vigorously. What better than to detect when a user is shaking his/her phone and provide a way to blow off some steam, and give feedback? That is what Google did: shake your iPhone when you have the Google Maps app open, and it will show this feedback view. Very smart of them.
ece

Even better than before

I’d say the app is way better than before Apple decided to move it out of iOS 6. Fast, public transportation and turn-by-turn navigation, as well as some very interesting new user experience elements. What do you think?

Now, originally Lean Startup was developed by Eric Ries while working on web products. Web sites can easily be shielded from non-invited users (for private betas) or you can put a beta label on it and users will understand it will be limited. You can instantly deploy new versions and there are lots of tools for all kinds of testing available. For A/B testing there are tools like Optimize.ly, Google analytics for statistics or user feedback via GetSatisfaction or UserVoice.

However, native mobile development has some characteristics that make it hard to apply the Lean Startup methodology:

1. Distributing beta versions is hard - in particular for iOS you are limited to 100 devices, you need to get the UDID of all testing devices and create a profile with that information. For Android it is easier, you can create a special version and distribute to anybody.
2. Limiting access to published apps is not allowed - everybody has to have access to your app once it is in the Apple iTunes or Google Play store. Secret publication is impossible and you are not allowed to incorporate a login inside your app for a limited set of users.
3. Your app needs to be ready for launch - initial launch is a very important moment for your ranking and long term success, so your MVP needs to be pretty if not very good at launch. The store may feature you if you are really outstanding, and initial ratings and reviews will have a profound effect on your subsequent downloads and thus ranking.
4. Updating takes time - putting out a new version of your iOS app takes 1-2 weeks for review so quick iterations are hard. It is only 30 minutes for Android fortunately.

So what can you do to follow as much as possible the Lean Startup methodology?

1. Develop mockups and test those - use paper and pen, Balsamiq or other prototype tools, get it in the hands of users and get their feedback.
2. Create non-native prototypes (i.e. HTML5) - easier to build than native, the product might actually work in a reasonable way and will be better at eliciting feedback from users.
3. For your beta use distribution tools –  like Mobtest other tools help you with distribution like Testflight or Hockey.
4. Focus only on a few features of your native app, but execute these really well - prioritize features and only build those that are required to offer some initial value that is good enough for users to keep on using your app.
5. Develop for only one platform first – learn from your first version, improve and once the product is good enough build the same app for other platforms.
6. Use A/B tools for native development – recently some tools like Clutch.IO and Switchboard have been released that offer A/B testing for iOS and Android.

iOS or Android first?
iOS still has most of the early adopters, and has users that actually are willing to pay for apps. Android as stated above has no review period and allows for easy beta distribution. So both have advantages, just don’t build two new apps for these two platforms at the same time but learn from one for the other.

So, with a few tricks applying Lean Startup for mobile is certainly possible. Using Lean Startup is important because you want to make sure you are building a product that offers value for your customers and you are going in the right direction.

Apple’s developer portal

When you as a iOS developer want to send out beta versions to testers, you need to create a build of your app with an ad hoc profile that contains the UDID’s from all the devices of your testers. Not only is that a painful process, you are also limited to 100 devices. That is, a 100 devices per developer license per year. When the iPhone 3 was released that was OK, but now it is becoming a major hurdle to do testing. It is time for Apple to change this policy. Here’s why:

1. fragmentation – now you have the iPhone 4, 4S and 5 as well as the iPad 2, 3, 4 and iPad Mini. Don’t forget iPod Touch 4 and 5. Also iOS 5 is still around (not for iPhone 5, iPad 4, iPad Mini or iPod Touch 5), so times 2 major iOS versions = 14 different devices.
2. developers create more apps per year - imagine a company that publishes 10 apps per year, for 10 different demographics. That 100 device limitation is for that one publisher, meaning you can have max 10 testers per demographic.
3. quality standards have gone up – There are 700,000 iOS apps out there. Only the best that get in a top 25 make money. High quality is required, so developers have to test thoroughly.

What could Apple do?

1. lift the 100 device limit up to say 1,000
2. limit the 100 device to a specific app
3. let go of the limit and allow for temporary ad hoc profiles that expire

Now that last one has my preference. No more collecting the UDID’s, managing them through Apple’s great and user friendly developer portal. Going back for every UDID that you get after testing has began. Let the profile expire after 2 weeks, with a popup “Download this app in the app store?”. No loss of downloads or revenue for Apple, more and easier testing for developers and publishers. What do you think?

So why did Apple suddenly come up with the iPad Mini, even after Steve Jobs public denouncements of the 7 inch class of tablets? It fits different use cases. Ten inch tablets like the iPad are just too big for a number of them. Operating an iPad for longer time without support of a table or your lap (on the couch, in bed) is hard. You cannot grasp the whole device with one hand. With 7 inch tablets like the Nexus 7, Amazon Kindle Fire and now the iPad Mini, you can. Imagine being a doctor, checking up on your patients while making your round through the hospital? Much easier. It will even fit in your doctor’s lab coat pocket. Seating guests in your restaurant or writing names and phone numbers down for your waiting list? A breez. Demoing at conventions, or writing down email addresses of interested people? No more need for an iPad grip, just one hand. I bet you that businesses will love the iPad Mini for data entry much more than the normal iPad, that shines at media consumption at home. And the fact that Google/Asus and Amazon and have had some first well selling tablets in this category, highlighted by the Nexus 7 trashing by Schiller, indicates that Apple couldn’t stay behind and had to come with an iPad version in the 7 inch category.

The iPad mini has the same resolution as the the original iPad (not Retina) so that iPad apps do not need to be changed to be run on an iPad mini. I would doubt if this is 100% true. In particular button size is related to the size of fingers, and while the number of pixels might be the same, the physical area of the button will be less for the iPad mini. This reduced the touch area so it might be harder to operate buttons on the iPad mini. Same can be seen with Android tablet apps that were created for 10 inch tablets and run on 7 inch.

I seldom take my iPad out of my home, I do in particular for conferences when I will be using Twitter a lot for a whole day. Stronger wifi, better battery life makes the iPad better than an iPhone. When do you take your tablet with you? And what do you expect from the new iPad mini?

My testing by network sniffing confirms that no more HTML is returned from the Facebook servers but JSON, the preferred format when using REST technology. JSON just gives you the data, formatting needs to be done by the code inside of the app. Most iOS apps that retrieve server data use JSON technology, so that was a no-brainer. According to their development blog post, many more different optimisations were implemented, including offloading actions to background threads (iOS 101), caching of computations how long text should be displayed, caching of heights of rows in the UITableView. Most of the app is native now. Still some lesser used parts are leveraging HTML technology, to allow for flexibility.

So is it faster? Yes it is. It is pretty fast, and seems to be fast enough. Open up the app, within a second the timeline shows, a couple more you have your updates. Mobile users need to be served even faster than web users, so this is good. Another complaint often heard was inconsistency of information, like getting a red icon indicating new messages but when you open the tab no new messages show up. That also seemed to be fixed, although a lot of different JSON calls are done to the FB backend, so hopefully these systems stay in sync.

User interface wise, the app seems to have become more basic. The new design direction of the Facebook Camera app is not followed. This rewrite seems to be done mostly by the engineering department to speed up the app. Hopefully the design department is now allowed to come up with new nicer designs like the Instagram or Path app.

Facebook chose HTML technology to allow for cross-platform development and faster updates. In the process it developed a suboptimal iOS app for users that are spoiled by awesome and speedy apps. An app that takes 60 seconds to load versus the 5 seconds that users want, sacrifices user experience badly. Facebook has now seen the light, turned around and gone back to fully native. HTML technology has its place, some companies like LinkedIn manage to build great iOS apps but most HTML/hybrid apps are slower than native, and developers should be fully aware of that. Facebook took a lot of heat for their HTML choice, their going back should be applauded and a lesson for us all. Let’s see what the users think.

Another note about Apple, the review process really hurts companies that want to iterate faster than 1 week. That Facebook was willing to go HTML to circumvent their process is a big indicator of that. Now for new apps and new companies, I would not change the way things work. But for trusted companies like Facebook, in particular a company that like Twitter is integrated on OS level, there must be a faster way of getting updates out there? I’d think so.

Current app had an average rating of 2 stars. I think it deserves 3.5 stars. What do you think?

Get the update from iTunes.

On the iPhone in 2008/9, before the iPad was out, the first version of the Facebook app was seen as one of the great examples how to build an iPhone app. It was developed by one person, Joe Hewitt, and parts of the app were open sourced as the Three20 project. When he left Facebook and stopped working on the iOS app, a new team took over which resulted in a complete rewrite for a universal app that also supported the iPad (November 2011). In spite of growing numbers, not a whole lot of users actually like the current iOS app. In the US iTunes store, the rating average is 2 stars, with out the 21,803 ratings, 11,839 1 star ratings (!). One star ratings are often a sign of frustration, and you can see that in the comments. For most of the apps an average of 2 stars is deadly, but we all use Facebook so yes we will all have to use its iOS app if you own an iPhone or iPad.

So what is wrong with the iOS app?

1. app is slow 
2. inconsistent information notification icons say there are new messages or responses, actual window does not show anything new.
3. app is slower than mobile web site while everybody is used to speedy apps, the Facebook mobile web site is faster than iOS app, and offers almost the same functionality.
4. tons of other bugs scrambled views, photo upload, text boxes disappear, no sharing.

What is the origin of these issues?

1. HTML and UIWebViews without Nitro JavaScript engine
I did some network sniffing (I like sniffing ) and found out that the data that the iOS app downloads from facebook.com is a mixture of REST (XML format, no JSON) and HTML. The HTML is used for your personal timeline, and profile and groups timelines. See for yourself, go to https://m.facebook.com/home.php and see that it is the initial view of the iOS app. Also from the screenshot above, you can see something went wrong while downloading the html and images/stylesheets/JavaScript. To display HTML in an app, a developer uses a Safari component called UIWebView. Very convenient, but also dangerous. The HTML downloaded is pretty big (15kb), and contains links to images, stylesheets and JavaScript. For a starter, caching of unchanged content cannot be controlled by the developer. The FB app downloads the whole timeline HTML every time, and it is up to the UIWebView to determine whether it needs to download images, stylesheets etc. again. Second, performance of UIWebViews is less than in mobile Safari. This has a lot to do with the absence of the new Nitro JavaScript engine in UIWebViews, apparently for security reasons. I ran some tests on my iPhone 4 with iOS 5.1.1, the JavaScript benchmark Sunspider running in Mobile Safari was 3 x as fast as running in a native app with a UIWebView. Also, to communicate from the UIWebView to the native app, a JavaScript bridge is needed. This is tricky stuff, slow and not really thread safe.

2. Different calls for similar information that is not in sync 
For notifications, messages and friend requests regular REST calls are done, returning XML data. First check is to see what number of new notifications are there (https://api.facebook.com/restserver.php), then the actual content is retrieved in a separate call (https://api-read.facebook.com/restserver.php). As far as I can tell, the Facebook service calls return inconsistent information. When you check too fast what new notifications are awaiting you, you don’t get the new information.

Why would Facebook use HTML technology inside a native iOS app?

1. HTML is easier for displaying fluid content. Objective-C really sucks when it comes to fluid display. An image with text around it, buttons with varying text labels are really hard to create yourself in Objective-C as you have to calculate dimensions and positions of all elements yourself. In particular for a timeline HTML will be much easier.
2. Creates code that can be shared across different platforms. iOS, Android, BlackBerry, Windows Phone are all different technologies and a developer’s nightmare. Sharing some content/functionality in the form of HTML makes sense.
3. HTML is much more in line with Facebook’s continuous deployment process. FB developers are responsible for their own QA, and part of that is to push code out to a limited set of servers, see results and then push it out to more and do this each day if not more often. With Apple taking as least a week of review, rolling back a code change is a nightmare.
4. They can get away with it. Yes Facebook is not a bank, there are no other iOS FB apps out there and we will still use the service as it has a virtual monopoly on social networking with 900 million users now. We just have to suck it up.
5. Feature phones is where growth is. A very high percentage of iPhone and Android users already have the Facebook app installed. The next frontier is feature phones, in particular in non-western parts of the world. These new users will first encounter Facebook on their mobile, and it will not be a shining iPhone.

For a company like Facebook a slick and fast fully native iOS App like Path would be much better. Faster means better user experience which will lead to higher user engagement. And higher user engagement is key for better monetization through ads. I’m afraid it will not be soon . What do you think?

As this nice infographic from Apppromo.com shows, top earners spend an average of 14% on marketing and have an average marketing budget of $30,000 dollars. Yes, that means it is really hard to make money if you are a small team with no cash in the bank. But with so many apps out there and the iTunes and Play store not really facilitating discovery, you need to get your customers attention somewhere else.

So how can you do app marketing?

• Do PR: blog posts, youtube video’s, build an app web site or send out a press release to tech news sites and bloggers
• Buy ads from companies like Admob or Milennial Media
• Buy incentivized downloads from companies like Tapjoy, although these users will probably not become active
• Get promoted through platforms like Appsfire, Chartboost or Hooked

Edit 1: also very interesting thread on Hackernews about a story written on Ars Technical about this infographic.