Archive for the 'Android' Category
The first handset from Finnish smartphone startup Jolla is simply called Jolla. This phone has been some two years in the making - a timeframe that testifies to the complexity of building handset hardware and a new mobile platform, not to mention rallying developers and achieving Android compatibility. So really two years ain't bad for a plucky startup whose members used to work for erstwhile king-of-the-mobile-world, Nokia, and left to do what that phone maker decided it couldn't: make a go of MeeGo as an alternative to Google's all-consuming Android.
What was MeeGo on Nokia's N9 is now Sailfish on Jolla's eponymous handset. The Jolla phone finally launched on Wednesday, in Helsinki, with the first 450 devices taken home mainly by those who had already registered their interest via a pre-sales campaign. Jolla is now shipping handsets to other pre-orderers throughout Europe. The top three countries for pre-sales were, in order of popularity, Finland (as you'd expect), Germany and the U.K.
TechCrunch got hands-on with Jolla's first phone for a few hours at a London press event, where two co-founders, Marc Dillon and Sami Pienimäki, were also on hand to answer questions.
The Jolla phone hardware reforms the standard smartphone slab into an attractive plastic sandwich, as if two blocks of different coloured liquorice have been smacked together. The back piece - which was plain white on the above demo device but comes in bright pink for Finnish carrier DNA's first batch of the phones, and in customisable colours in future when Jolla starts direct sales via its own website - is known as The Other Half.
Like Jolla's software The Other Half is intended as an extensible platform - with connectors built into the back of the phone for power and a bus connection for data transfer allowing for Other Halves that could incorporate a physical Qwerty keyboard, for instance, or a weather station sensor or even an e-ink screen, as well as the NFC-powered software theme-swapping supported by the current crop of shells.
“Putting something like a keyboard is expected,” said Jolla co-founder Marc Dillon. “We are working on the developers kit so that anybody can do this… We're working on accessories, and we expect third parties to work on accessories.”
The standard Jolla handset (i.e. with a not-too-fancy Other Half) is a nice size and weight in the hand - neither too big to be overbearing, nor too hefty or lightweight to feel unpleasant to hold. On paper, its specs come across as relatively mid-range - with a 4.5″ display, a dual-core chip, 4G, an 8MP camera plus 16GB of internal memory expandable via microSD card. But differentiating on phone hardware specs is not what Jolla is all about.
Its difference lies in the MeeGo-derived Sailfish software platform, and an open philosophy that wants developers - and other companies - to come in and build all sorts of software and hardware extensions atop this platform. The Jolla phone is a showcase for what Jolla the startup can do - tl;dr: see here what we built for ourselves, why not let us build something for you?
“You can't really have an operating system without a spearhead device, and although we've been talking to almost everybody that's in the mobile space over the last two years, almost every kind of manufacturer, I think they've all been waiting to see what we actually are capable of,” Dillon told TechCrunch.
“Because if you just look, people wise, then we're really small compared to these guys. Their coffee budget is probably as much as we've spent to create this device!… So now they have a way to judge our capabilities by taking a real device and looking at it, and seeing what it does.”
Despite this b2b sales pitch, Jolla is committed to its own consumer play too - believing there is appetite for something new and different to shake up the samey-same smartphone space.
Dillon said about 80% of those who pre-ordered its handset earlier this year - in some instances without putting any down money down - have been converted into sales. Jolla hasn't confirmed exactly how many devices were pre-ordered, saying only that it was a “typical” sized production batch - of up to 50,000 units. But it did take in €1 million's worth of sales on the phone's launch day, according to Dillon.
Doing a back-of-an-envelope calculation, by dividing that figure by the phone's standard €399 price-tag, equates to 2,500 Jolla handsets sold in one day. Albeit, the pre-sales campaign muddies the water a little. Either way, generating €1 million in revenue in a day ain't bad for a new kid on the phone block.
Indeed, getting a smartphone to market when you're a startup of 80+ full-time employees, not an electronics behemoth like Apple or Samsung, is a monumental achievement in itself. But it is also just the start for Jolla. Now the even harder work of community building kicks off in earnest - if it's to turn one phone into a whole new-wave open mobile movement.
Passion projects attract fans. And Jolla is clearly a passion project for Dillon, who tells me he personally shook the hand of everyone standing in line in Helsinki's Narinkka Square for Wednesday's Jolla launch. And for all the ex-Nokians who made the decision to leave to carry on developing a platform that Nokia was abandoning.
Jolla's early buyers are also clearly passionate about the potential of (another) homegrown mobile platform. The question is whether Jolla can build a community beyond these nostalgic origins. Dillon argues it's already doing that - and that the launch event was characterised by a broad spectrum of interest.
“There was everyone from high school students to retired people. There were men and women, different nationalities - there was of course a lot of Finns, being Finland, but there was also people had come in from some other countries,” he said.
“That was one of the things that we were actually curious about. Usually you have a set of early adopters for a new technology platform - we seem to break that. We had a very wide demographic who was taking our first device.”
I believe that people are looking for something different. Imagine if you could only buy two car choices in the world.
Why does he think Jolla is attracting diversity? “I think that the reason that people have had a lot of interest in us is there's this David vs Goliath thing but also the fact that instead of just being a corporate face we're coming out as people and we're interested in people, and we are people, and I think there's been a personal connection that we've made with a lot of people.
“And I believe that people are looking for something different. Imagine if you could only buy two car choices in the world. People can only buy what's offered to them - and they've have had the same kind of experience for five years. So there's a curiosity to see what happens next.”
But launches are by their nature exciting. The everyday reality of technology is that people crave the unexciting stuff too - functionality, reliability, stability, simplicity, (app) familiarity, and so on. Those are areas where Jolla has work to do. Its new mobile platform is inevitably an oxymoron: it's both shiny and rough round the edges.
The Jolla UI is different to Android and iOS, excitingly so, to the point where you can feel its potential to offer something fluid, flexible and freeing to use. It also generally feels fast and responsive - although there is a small lag when opening or switching between apps, and progress bars pop up for certain actions which you might not expect, such as deleting a single photo.
But it's inevitably still got a lot of kinks to iron out, including actual bugs that cause apps to crash or mess up, but also counterintuitive quirks - things not always working as you'd expect. One of the biggest challenges for Jolla is undoubtedly the learning curve its newness demands of users now fully embedded with icon-based, back-button-sign-posted mainstream user interfaces.
Navigating around Jolla's UI requires a different set of gestures to iOS and Android; there's no back button, there are very few buttons at all - it's more push and pull, more like BlackBerry 10 or even Windows Phone, with gestures for peeking at content, and pulling in more stuff lurking off screen. (Of course Jolla would say its interface is Unlike all the rest.)
Other gestures close or minimise apps - the latter being displayed as small widgets on the homescreen which you can also interact with, if the developer has added in such functionality. So, for instance, you can refresh a webpage from the browser widget or command it open a new tab, or dive right in to search for an app on Jolla's app store just by swiping left (or right) on the corresponding homescreen widget.
To navigate generally, the user has to follow subtle clues - such as a glowing bar that sometimes appears at the top or bottom of the screen or a menu, to signify there's a list of actions that can be dragged on screen and selected within the same movement; or breadcrumbs of dots that appear at the top corner of the screen, which signify there are other screens' worth of content waiting to be swiped into view.
Getting the hang of these elements is not the work of days, but it does take patience and a willingness to learn something new - something Jolla unfortunately can't take for granted. Users also have to contend with Sailfish gestures being combined with Android nav elements (such as the Android back button and recent apps key) when running Android apps. Which dilutes Sailfish's signposts with the very Android paradigms it's hoping to supersede.
“We got rid of the home button - so we did eliminate one of them, but the back button, unfortunately, even though we have our own forward and back solution the [Android] applications still [use] so we still have to have those buttons,” said Dillon.
Jolla is working on getting a community portal rolled out to its website, which will include a forum where users can help each other out with queries - to supplement its already launched online care channel. It's also making a series of how to videos to explain Sailfish navigation and gestures. And will be staffing a variety of social media contact points where people might be looking for answers, says Dillon. Plus there's an on-device tutorial that walks users through the gesture basics.
All of this will certainly help, but getting people to switch from something they know to something different is by definition pushing water uphill - as Microsoft's long hard slog to get Windows Phone to stick underlines.
Then of course there is the big challenge for any ‘other' platform: the app gap that won't go away. Even with Android compatibility - and Yandex's app store preloaded - Jolla is inevitably starting a long way behind the Android-powered competition. In terms of native Sailfish apps (accessed via the Jolla store), there are but a handful at launch - I counted about 28 on the device, which includes basic stuff like an email client and a document viewer. There's also no support for paid Sailfish apps, as yet, but that important developer incentive is coming down the line.
And then Yandex's Android store presents only a smaller sub-set (apparently 85,000) of the apps Android users get on Google Play (one million+), so inevitably a lot of titles you'd find on bog standard Android are not on these shelves. (And while you may be able to sideload some Android apps, there's no guarantee of smooth or even workable compatibility with Sailfish).
Even tapping directly into the Android apps on the preloaded Yandex Store isn't a guarantee of smooth results as there are ongoing compatibility issues at this (early) point. Notably, the Android runtime sometimes spontaneously takes over the interface, dragging the user back to an Android app they had quit out of, as if Mountain View is wrestling back control from this open mobile upstart.
Compatibility issues also mean Android apps can appear buggy, with elements failing to correctly mesh with native Sailfish elements such as the keyboard, or degrading the experience so the app feels sluggish. On the other hand, other Android apps - such as Twitter - seemed to perform ok during my hands on so it's not all bad. But it is inconsistent, and Jolla's Dillon concedes the startup does have work to do on the Android compatibility front.
Regardless of myriad consumer-facing challenges, he says Jolla is in it for the long haul. It's committed to providing its early adopters with a device that improves and continues to evolve, rather than hardware that withers on the vine (as Nokia's N9 did). “The most important thing for us is that we continue to add value for everyone that bought this,” he said. “What features we do next, we believe the consumers should have a say in what the priorities are - and we will continue to deliver new features via the software.”
Jolla apparently has enough funding to sustain that effort too - with an alliance of industry backers committing to buoy up Sailfish to the tune of €200 million. Back in February Jolla itself also took in a €1 million investment from a Hong Kong based telecoms & mining firm, China Fortune, in exchange for 6.25% of the company. Chinese e-commerce giants Alibaba and Baidu have also been floated as future potential partners for Jolla - albeit that might just be wishful thinking at this point.
Jolla co-founder Sami Pienimäki said the company's already spent about €20 million getting to the starting point of being able to release its first handset, running the Sailfish OS. How much more it may need to nurture and build out an ecosystem to really get Sailfish moving remains to be seen.
But why might other mobile makers want to use Jolla's software to power their own devices? ”Just using Sailfish is a differentiator already because we were able to take a fresh look and do something new,” said Dillon, when I pose this question. “We [also] have no competing services, or no required embedded services” - a veiled reference to how Google tries to keep its Android OEMs (and developers) in line, by dangling the carrot of access to its Play store.
Beyond ‘not being Android', Dillon argues that Sailfish is a place where the next wave of mobile innovation can occur - a liberal space for experimentation, for forming a way beyond the status quo of segmented services and individual apps consumed in a cacophonous pick'n'mix. Somewhere where smarter, more unified and better targeted services can be developed.
This is just the beginning of how I believe mobile's going to start to break this application barrier.
“What I think the platforms are going to do - and where a real differentiation is going to occur - is when services start to get integrated here [on the homescreen] and not just sticking your application and embedding it into the device but actually connecting multiple applications together to make a more seamless experience,” he told TechCrunch.
Instead of users harvesting data from multiple apps and places individually within a device, Dillon envisages a platform where more and more apps plug into each other to funnel data to where it's needed rather than sitting in separate silos that the user is required to visit.
“I don't want to deal with events the second that they happen all of the time, so when I look [at my Jolla phone] I see that there's these phone calls that I've made, so there's a constant reminder that these are the people in my life at the moment that I'm communicating with… The same with messages… or email… This is just the beginning of how I believe mobile's going to start to break this application barrier,” he said.
“These kinds of synergies between things is just starting, so that you don't have to cross apps all the time,” he added. ”What we're doing is we're creating a place where these things - well beyond what I can think of or tell you today - are going to occur.
“The openness of the platform lets a developer, a company, an entrepreneur, a new business take something from the user experience all the way down to the hardware, the metal, the silicon - across to one or more Internet services, and provide something that is going to connect a user to one or more services that are locally relevant, that are important to you right now and not spammy.”
All that is for the uncertain future. For now, Jolla has shown a startup can make a smartphone. So it's already proven a lot of its doubters wrong. It's also positioned itself to take up the baton from Nokia, as THE Finnish mobile maker - just as Nokia prepares to give up that role (by selling its Devices & Services unit to Microsoft). Which is cruel or opportune timing, depending on your perspective.
Building a new smartphone on a new platform is already an impressive achievement. But Jolla isn't about to stop and admire the view. This startup has no intention of letting a single lovingly crafted handset remain its crowning glory. Onward Sails!
In between chowing down on turkey, slurping up cranberry sauce, and sucking down a cold beverage or two with friends and family, we’ve been busy shopping.
At least 10 percent busier than last year, according to IBM.
According to the IBM Digital Analytics Benchmark, which tracks millions of real-time transactions and analyzes terabytes of data from more than 800 retail sites nationwide, smartphones drove almost double the traffic of tablets today, likely because we’re not at home, and our smartphones are handier.
Smartphones drove 23.5 percent of all online traffic, compared to tablets at more than 13 percent, making it the browsing device of choice,” IBM said in a statement. “When it comes to making the sale, tablets drove more than 14.6 percent of all online sales, more than one and a half times that of smartphones, which accounted for 8.6 percent.”
Tablets also drove higher average order value than smartphones. While the average smartphone order totaled $113.50, the average tablet order topped $127. All told, mobile traffic was up 31 percent year-over-year, accounting for 37.5 percent of all shopping traffic. And online sales were strong, IBM said, with 23.5 percent of all sales being consummated on a mobile device.
As usual, iOS outpaced Android by a significant margin.
iOS drove almost four times the sales of Android, and iPhone owners spent an average of $122.55, while Android users averaged $113.50 per order. iPhone and iPad owners also drove more traffic than Android — 26 percent versus 11 percent.
Interestingly, orders originating on Facebook were higher-value than those starting on Pinterest. Usually Pinterest drives higher order value, but today the average shopping expedition that began at Facebook was worth $106.86, versus $102.79 from Pinterest. In addition, Facebook referrals converted a shocking 84 percent more than Pinterest referrals … “perhaps indicating stronger confidence in network recommendations,” IBM said.
Well that didn't take long. Google has asked Cyanogen Inc. to remove its alternative Android ROM installer app from the Play store.
Cyanogen raised $7 million from Benchmark Capital back in September to turn its geek-beloved aftermarket version of Android into a mainstream flavour of the platform - with the ultimate aim of using an Android variant to compete with standard Android (and iOS) for consumers' attention.
To kick off its mainstream market targeting effort, Cyanogen released an installer app for its CyanogenMod earlier this month - to make it easier for less tech savvy Android users to flash the ROM on their devices.
But, writing in a blog yesterday, Cyanogen said Google's Play support team had contacted it to ask it to remove the app, citing violations of Play's developer terms - warning that if the app wasn't voluntarily removed it would be forcibly ejected.
So Cyanogen's attempt to boost the popularity of its Android-based alternative to Android apparently got Google's attention too.
At the time of writing Google had not responded to requests for comment on why it asked Cyanogen to remove its installer app.
But here's what Cyanogen said Google told it:
Today, we were contacted by the Google Play Support team to say that our CyanogenMod Installer application is in violation of Google Play's developer terms.
They advised us to voluntarily remove the application, or they would be forced to remove it administratively. We have complied with their wishes while we wait for a more favorable resolution.
To those unfamiliar with the application, it has a single function – to guide users to enable "ADB", a built in development and debugging tool, and then navigates the user to the desktop installer. The desktop application then performs the installation of the CyanogenMod on their Android device.
After reaching out to the Play team, their feedback was that though application itself is harmless, since it ‘encourages users to void their warranty', it would not be allowed to remain in the store.
Android being an open platform means users can still download and install Cyanogen Mod via a number of routes, including from Cyanogen's own website.
However, if you're on a mission to lower the barrier of entry to your alternative Android firmware, requiring people to seek out and sideload your software rather than stumble across an installer app sitting on the shelves of Google's mainstream store does make that mission a lot harder - as Cyanogen's blog post goes on to note:
Fortunately, Android is open enough that devices allow for installing applications via ‘Unknown Sources' (ie sideload). Though it's a hassle and adds steps to the process, this does allow us a path forward, outside of the Play Store itself.
According to Cyanogen, the installer app was downloaded “hundreds of thousands” of times in the two weeks+ it was available on Google Play, which it argues proves “the demand for more choice” - another reason Google may have started feeling uncomfortable about the installer's presence on its store. Android may be an open platform but Google Play is very much ‘made and maintained in Mountain View'.
Cyanogen is clearly hoping to resolve the Play blip if it can. “As we work through this new hurdle, we will continue to make available and support the installation process via our own hosting services,” it added in its blog.
Why might the average Android user want to install Cyanogen Mod? It's a way to ditch the bloatware and crapware loaded onto many Android devices by carriers, for instance, or to remove a custom Android skin - such as HTC's Sense UI - that's irritating or slows down the Android experience.
Custom skins also typically delay the process of getting Android updates, and can also force Android users to be stuck on older version of the platform even if their device hardware could technically handle an upgrade.
Cyanogen Mod also includes features not offered in standard Android - including native theming, an OpenVPN client, support for Wi-Fi- Bluetooth- and USB-tethering, CPU overclocking and FLAC audio codec support.
In addition, Cyanogen argues that its ROM can increase the performance and reliability of Android compared with official firmware releases.
Why might Google be nervous about Cyanogen? If an alternative Android platform was able to gain significant traction it could undermine Google's monetisation of Android - via the services it preloads onto Android (such as Play, Maps, YouTube) - by providing an opportunity for other services to be preloaded instead (as is often the case in the Chinese market).
It could also weaken Google's control of Android, and it could erode the attractiveness of the platform in carriers' eyes, making them less keen to promote Android devices to their customers and in their retail stores if they can't be sure their users won't be saddled with their branded bloatware.
Holiday weeks tend to be a little quiet, but there's always something going on in the world of Android to dig into. This time around, though, Darrell and I roped in MobileSyrup's Daniel Bader and our very own Natasha Lomas to liven things up before it goes quiet for a few days. And I daresay we pulled it off nicely.
Oh, but you want details. We four jolly bloggers couldn't help but dig into BlackBerry's curious new BBM preloading deal with Android device OEMs, and it wasn't long at all before Dan and I shifted the conversation to the joys and tribulations of loading some custom ROMs on your smartphone (for the record, he's a fan of Paranoid Android). Throw in some kooky startup ideas and some even more outlandish funding offers, and you've got this week's show in a nutshell.
We're not exactly the sappiest people you'll ever meet, but we even had ourselves something approaching a heartwarming moment. Despite the fact that I'm the only one of the four who's actually celebrating Thanksgiving tomorrow, I made everyone sit in a make-believe circle and share what they're thankful for. Guess who went the classy route and chose something alcoholic? (Hint: it was Darrell.)
We invite you to enjoy weekly Android podcasts every Wednesday at 5:30 p.m. Eastern and 2:30 p.m. Pacific (generally speaking), in addition to our weekly Gadgets podcast at 3 p.m. Eastern and noon Pacific on Fridays. Subscribe to the TechCrunch Droidcast in iTunes, too, if that's your fancy.
Intro music by Kris Keyser.
Direct download available here.
Android 4.4 KitKat update is now available for people who use the Google Play editions of HTC One and Samsung Galaxy S4. They follow Motorola's Moto X, which first got access to Android 4.4 KitKat on Nov. 19 less than one month after Google revealed it.
Back in October, Google told TechCrunch that KitKat was designed to reach the next billion Android users in developing markets, which means that Google had to figure out how to create an OS that can bring older and lower-specced devices up-to-date, as well as helping third-party developers offer their content to all Android users, not just those with top-tier handsets. Android 4.4 KitKat's new features include a new launcher, a new dialer that incorporates search, Hangouts with consolidated text, video and MMS, new HDR+ software for cameras and deep app linking for Google search.
But the version of KitKat on the Moto X and the Google Play versions of HTC One and Samsung Galaxy S4 doesn't have the Google Experience Launcher available on the Nexus 5, which was unveiled at the end of October. The Google Experience Launcher, meant as a Nexus 5 exclusive, lets you swipe left for Google Now, trigger Google Search through an “OK Google” hot keyword and has a new options for customizing the look of your operating system.
The Google Play editions of HTC One and Samsung Galaxy S4 differ from the ones sold by carriers in that they are offered unsubsidized without a contract and operate on “pure” Android rather than the company's customized skins.
In October, Apple owned the six of the highest-revenue apps in the iOS app store. And corporate friend-of-the-family Disney owned the next four, rounding out the top ten, as Distimo’s apps and brands mobile report shows:
- Disney Junior Appisodes
- Seven Dwarfs, the Queen’s Return
- Hidden Objects: Gardens of Time
- Alice in Wonderland: A New Champion
The fact that Disney is excellent at extracting revenue from the willing wallets of mobile consumers might not be a big surprise. After all, the movie magic company has always been good at monetizing entertainment. But the fact that Apple is number one (and number two, and number three, and so on …) on its own platform is surprising, and even a little odd.
Apple, of course, can manipulate the iOS app store to feature any products it chooses, if it want to drive a particular type of purchasing behavior, or feature a particular kind of app. Which doesn’t mean the company has use that power, of course, in any unfair way.
But it can.
In any case, the situation will not last long. Apple has made its iWork apps — Pages, Keynote, and Numbers — free with the purchase of any iOS device. And iLife, which includes iMovie, iPhoto, and GarageBand, is getting precisely the same treatment.
Which means, of course, that the only people who would consider buying these apps in the future have old iPhones, iPads, or iPod Touches, and that the free version is a pretty big incentive to upgrade to new hardware. And which means that Apple’s days of leading the leaderboard are almost certainly over.
Which is probably better for Apple’s image of driving huge wads of cash to independent developers, anyways.
VentureBeat is creating an index of the most exciting cloud-based services for developers. Take a look at our initial suggestions and complete the survey to help us build a definitive index. We’ll publish the official index later this month, and for those who fill out surveys, we’ll send you an expanded report free of charge. Speak with the analyst who put this survey together to get more in-depth information, inquire within.
Mobile devices are approaching half the traffic coming to restaurant websites — a sign that small businesses need to get smart about mobile website design.
According to Goro Harumi, the founder of LetsEat, a website builder for restaurants, the average percentage of traffic to restaurant sites has risen from 3 percent fours years ago to 43 percent today. On weekends, the number approaches 50%.
“2014 could be the first year many business owners opt to skip desktop website designs and go 100% mobile,” Harumi said.
That’s because the expense of hiring designers is high — particularly relative to the budget of a small business. If half your customers are already accessing your site using Android devices or iPhones, and that number is only rising, you might as well save half your design costs and optimize for mobile from the start.
Harumi has been tracking the traffic to restaurant websites his platform hosts since 2009, a data set that now spans 14,000 restaurants. That gives him a broad perspective on the trends facing this niche market.
Interestingly, mobile usage varies by city, and the most mobile city is not what you’d expect: Harumi’s data set shows that the Chicago area leads other metro regions, with 48 percent of restaurant customers using mobile devices. In San Francisco, which is a tech hub in other ways, only 41 percent of customers use mobile.
As restaurant customers go, so too may the customers of other businesses. Business owners: Get ready.
Hat tip: LetsEat blog
Nintendo is reportedly making an Android tablet that will be primarily for the educational market, according to a series of Twitter posts from Nintendo of America software engineer Nando Monterazo.
Experimenting with a tablet of Nintendo, the system is based on android, fully modified and unified as a database of the tablet. #Android
— Nando Monterazo (@NandoMonterazo) November 18, 2013
At the moment just testing communication environment of educational games that will be shared between the kids using the tablet! #Tablet
— Nando Monterazo (@NandoMonterazo) November 18, 2013
We contacted Nintendo, and a representative responded that “Nintendo does not comment on rumors or speculation.” We also contacted the rep on the phone, and that rep said Nintendo wouldn’t comment on whether Monterazo was a company employee.
Despite the Nintendo connection, Monterazo said that NES, Super Nintendo, and Game Boy games will not appear on the tablet, with “educational games only” being the focus.
Monterazo also said that the unnamed tablet’s educational games will feature certain Nintendo characters, which could include company mascots Mario and Luigi as well as characters from other first-party Nintendo titles.
— Nando Monterazo (@NandoMonterazo) November 18, 2013
Although Monterazo said that old-school Nintendo games will not work on the tablet, this may not necessarily be true if the device is running Android.
As an open-source platform, Android is well known for its emulation capabilities, including running ROM files for a wide variety of gaming systems such as the Super Nintendo, the original PlayStation, and arcade platforms like the CP System II.
Either way, this could be significant, since Nintendo has historically resisted moving into the mobile market.
For comparison’s sake, that’s roughly four times as many units as the Nintendo Wii’s sold in its own lifecycle, which began over seven months before the debut of the original iPhone.
The eternal startup question “Android or iOS first?” grows ever thornier, with news that Android's market share exceeds 80%. But never mind the managers and non-technical founders: what do developers! developers! think of that divide? Whoever makes life easier for them gains a sizable edge.
And by “them” I mean “us.” When not writing TC columns (and novels) I'm a software engineer for HappyFunCorp, a consultancy with the best name (and web site–go on, click through) ever. To keep my hand in, as I find myself doing ever more management, I recently wrote and open-sourced a pair of more-or-less identical Android and iOS apps for a pet personal project. So let me use them to walk you through the state of the art.
Background: I've written numerous Android and iOS apps previously, both personally and professionally. These apps are native clients for my pet news aggregator, Scanvine, which identifies stories being shared unusually widely across social media. Their complete source code is available on Github: (Android | iOS) and the actual apps are available for download: (Google Play | App Store.)
Before we begin, I would be remiss not to mention Xamarin's cross-platform development tools. If I was fluent in C#, especially if I didn't already know Java and Objective-C, that would be my first choice for native app development.
Also, a disclaimer: this is more “fun code” than “production quality.” You'll notice a stark lack of test code; I still need to track down an iOS heisenbug; I should be using git submodules rather than copy-pasted files for the third-party libraries; etc. (eta: ugh, and a rogue layout file slipped into the Android build which caused it to crash on tablets. Now fixed.)
Now, with no further ado, let the battle commence!
You can still write code with text files and command lines, and many do, but it's so much more productive to use an integrated development environment, or IDE.
Apple's is Xcode, which is, by and large, a joy to work with. It's slick, fast, powerful, helpful without being intrusive, and it keeps getting better at papering over both the unheimlich compilation machinery beneath its glossy exterior, and the complex and paranoid certificate/profile machinery which Apple imposes on developers to retain its titanium-fisted control over iOS apps and devices. The debugger works seamlessly, and the simulator is fast and responsive.
But Android? Oh, Android. The current state-of-the-art IDE is Eclipse, customized with Android plugins, and it is embarrassingly bad. Slow, clunky, counterintuitive when not outright baffling, poorly laid out, needlessly complex, it's just a mess. Its debugger is so clumsy that I find myself doing log-file debugging most of the time, whereas the XCode debugger is my iOS go-to bug-hunt tool. And the less said about the Android emulator, which takes minutes to launch and then half the time fails to connect to the Android Debug Bridge, the better.
Do people really use the android virtual device thing for development? Why does it take like ten minutes to boot?—
(@midendian) October 31, 2013
Now, to be fair, Google knows this is a problem, and they are working on a new Android Studio IDE. Alas:
Android Studio is currently available as an early access preview. Several features are either incomplete or not yet implemented and you may encounter bugs. If you are not comfortable using an unfinished product, you may want to instead download (or continue to use) the ADT Bundle (Eclipse with the ADT Plugin).
It's nice to see they're working on it, but it's amazing–in a bad way–that 4.5 years after I purchased my first Android phone, this mess is still the state of the art.
Advantage: iOS, by a country mile.
As I mentioned, beneath the sleek, seamless exterior of Xcode and Objective-C lurk the Lovecraftian horrors of 1970s programming. I kid, I kid…but still. Macros and header files; projects, targets, schemes, and build configurations; an appallingly-intimidating list of build settings; the grim despair of encountering a baffling linker error; and discoveries like “oh, your third-party code doesn't support ARC? Just add the -fno-objc-arc flag! Simple, no?”
Android has a single manifest file and Eclipse builds your app in its entirety (usually) every time you save any file. I'd prefer more clarity in the error messages you get when your app isn't working because you haven't configured its permissions correctly, but that's a minor cavil. By and large, Android app configuration is simple and elegant.
You would expect Apple to walk off with this trophy. Its Interface Builder is a very sleek way to put simple good-looking user interfaces together quickly. The trouble is, the more I've actually used Interface Builder, the less I've liked it. It's another layer of configuration complexity; it's excellent for simple things, but as time goes by and apps evolve, those simple things tend to get complex and messy; and I really don't like the multi-screen Storyboards Apple added about a year ago.
While Android theoretically has a comparable visual tool, the less said about it the better. In practice you wind up writing XML files which provide layout guidelines, as opposed to rules, so that apps are rendered (hopefully) well on the entire vast panoply of devices and screen sizes out there. (Apple's Auto Layout moves in the same direction, with an eye towards a larger variety of iOS screens in the future, no doubt.) Meanwhile, Android provides an icon pack for developers to use, whereas iOS developers have to go with third parties like Icons8, or roll their own.
Overall it's a closer contest than you'd think, although I concede that this is pretty idiosyncratic. In the end two things give iOS the edge. First, it's still much simpler: three screen sizes (including iPad) and two screen densities, as opposed to the mass of complexity which is Android. Second, the default iOS visual elements - eg popup menus and messages – are so much more visually attractive than Android's.
Android apps are written in Java; iOS apps in Objective-C. There are exceptions – there's Xamarin, again; there are various other native-app fringe cases; and there are native/web hybrids like PhoneGap - but in general, native Android apps are written in Java and native iOS apps in Objective-C.
I cut my programming teeth on Java, and didn't think much of Objective-C at first, in large part because of its excessive verbosity: a line like
String s2 = s1.replace(“abc”,”xyz”);
NSString *s2 = [s1 stringByReplacingOccurrencesOfString:@"abc" withString:@"xyz"];
but I've grown very fond of Objective-C. It's just better and cleaner than Java. It has blocks: Java does not. It has categories; Java does not. It does not require you to wrap much of your code with vast swathes of boilerplate try/catch exception-handling whitespace: Java does.
Java has its advantages. Better stack traces, for one thing, which means tracking down sporadic bugs tends to be a lot easier. And until a couple of years ago Android had the huge advantage of garbage collection. But now that iOS has automatic reference counting, that advantage has mostly vanished (although old third-party tools often don't work with ARC, which means you have to do some XCode configuration voodoo to switch it off on a file-by-file basis.) With that distinction gone, the winner here is clear.
Both Android and iOS make an enormous library of software available to their developers, and, broadly speaking, those libraries are fairly similar: there are APIs for phone functions and features, network access functions, a panoply of View objects including a powerful WebView which essentially functions as a full-fledged browser. Most of the work, meanwhile, is done in controllers: very roughly, an iOS ViewController is equivalent to an Android Activity.
What iOS has which Android doesn't is an extra set of frameworks and features - there's no real Android equivalent to iOS's powerful Core Data framework, for instance - and a generally cleaner, better designed system. Compare these two relatively simple iOS classes, for instance, which really do the bulk of all the work in the app, with these three equivalent Android classes, which between them include a half-dozen more inner or anonymous classes. At the end of the day I'd just much rather work with an iOS CollectionViewController than an Android ListAdapter.
Another metric, albeit a flawed one: lines of code. These apps are very nearly functional identical, but the iOS one has 1596 lines of custom code, including header files, compared to 2109 lines of Java code and XML for Android. That's a full 32% more.
These days many-to-most apps are conduits to Internet APIs more than they're standalone programs; this is important enough that it's worth looking at separately. Both iOS and Android provide a panoply of tools and APIs for this. They also both provide very similar WebViews, which are basically full-fledged browser windows that you can plug into your app anywhere.
Network connections basically have to run in the background, so as not to block the main thread of the app, and multithreading is hard. Android provides an AsyncTask class for things like this, which is verbose but works well, and a very easy way to determine whether you're currently online. iOS provides equivalent facilities, but they're all pretty low-level and unsatisfying.
However, there are a host of open-source libraries that make life much easier. I used AFNetworking, which is as delightful as advertised. You simply pass it blocks of code to run when web requests are complete - which isn't possible in Android, because Java doesn't do blocks.
Advantage: Android natively, but iOS when third-party libraries are considered.
How easy is it to share something from your app to Facebook, Twitter, Evernote, etc? I had thought this would be a first-round knockout for Android, which has long had a powerful inter-app communications system called Intents. And in general Android is still much better at letting apps call and share data with one another.
In the (perhaps unfortunately) much more common case of sharing, though, Apple has caught up considerably. Don't take my word for it, judge for yourself. The Android code to share a Scanvine story is here, and the iOS code here. The only reason the iOS code is longer is because I do a little more Google Analytics tracking there than on the Android side (which I should fix.)
Publishing an Android app is easy as a dream. Just sign your app via a handy Eclipse wizard, and poof, you have an APK file that can run on any device. Email it, put it up on a web site, or upload it to Google Play and make it available worldwide (probably) within the hour. Could hardly be simpler. Check install statistics and crash reports, including stack traces which (usually) identify the individual line of code that went wrong, at your leisure, and you can upload a bug-fix version immediately.
Publishing an Apple app is a nightmare. A brilliant friend of mine always advises people to add at least a day to their iOS development schedule just to wrestle with certificates and distribution profiles. No matter how many times I do it, or how easy the latest version of XCode tries to make it, it's always a giant hassle. And testing would be even worse if not for TestFlight. And Apple's “iTunes Connect” web site is to Google Play Developer Console as a Ford Pinto is to a Tesla. Good luck getting any crash reports at all, much less useful information from them; have fun jumping through their arbitrary hoops; and marvel at just how bad mighty Apple's UX can be.
Advantage: Android, by a long shot.
And The Winner Is…
iOS, and by some distance. Android has its advantages, but overall, it remains significantly easier to write good iOS apps than good Android apps. Combine that with the fact that iOS users tend to be wealthier–and arguably more influential–and it still makes sense for most startups who want to make a splash to go iOS-first, Android-later. The new Android Studio IDE could conceivably close some of that gap…but not all of it.
(For the record, my own primary phone is a Nexus 4, and I'm very happy with it.)
Image credit: Jennifer Stolzer, DeviantArt.