android

News on mobile: better be a Danish publisher than a Japanese one

 

This is the second part of our Mobile facts to Keep in Mind (see last week Monday Note – or here on Quartz). Today, a few more basic trends and a closer look at healthy markets for digital news. 

Last week, we spoke about the preeminence of mobile applications. Not all readers agree, of course, but I found more data to support the finding; among many sources, the remarkable Reuters Institute Digital News Report (PDF here) is worth reading:

47% of smartphone users say they use mainly apps for news

According to the report, this figure has risen by 6 percentage points in just one year. By contrast, 38% of the news consumption is made via a browser — which is losing ground: -4% in just a year.

The trend is likely to accelerate when taking in account demography: On smartphones, the most active groups are the 18-24s and the 35-44s; on tablets the most active group is the 45-54 segment.

Platform usage varies in accordance to local market share, but when it come to paying for news, Apple leads the game:

iOS users are x1.5 likely to pay for news in the US
and x2 likely to pay in the UK than Android or other users

Here is the bad part, though. Again based on the Reuters report, the use of smartphones does narrow the range of news sources. More than ever, the battle for the first screen is crucial.

Across the ten countries surveyed,
37% of users rely on a single news source
vs. 30% for PC users

In the UK, the trend is even stronger with 55% of mobile users relying a single news source. This goes along with good news for those who still defend original news production: mobile news consumption is quite focused on legacy media. The BBC app crushes the competition with 67% of respondents saying they used the app the previous week, vs. 25% for Sky, MSN and Yahoo are trailing with respectively 2% and 7%.

If you want to survey a healthy digital news market, go to Denmark

MN_328_vikings_logo

A Viking logo (from the TV Series) as viewed by the Brand New blog;
note the ancient reference to technology…

Not only does Denmark rank among the best countries to live and develop a business in, but when it comes to digital news, it leads the pack in several of ways:

Despite the digital tsunami, Denmark retains many strong media brands. As a result, legacy media are the prime way for accessing digital news. And since Danish media did well embracing new platforms, they enjoyed similarly success on social, funneling readers to their properties.
The opposite holds for France and Germany where the transition is much slower; in those countries digital users rely much more on search to reach news brands. Two side effects ensue: News readers are more accidental and therefore generate a much lower ARPU; and the greater reliance on Google is problematic (hence the call to arms in France and Germany against the search engine giant.)

— Because of the strength of its traditional media brands, the Denmark news market has left very little oxygen to pure players: They weigh only 10% of weekly digital news, vs. 39% in the US and 46% in Japan were legacy media have been severely hit.

— Danes are the heaviest users of both smartphones and tablets to access news.

— They use mobile apps more than anywhere else: 19%, vs. 15% for US and 12% for Germany.

— They are mostly Apple users : 58% say they use an iOS device to access news in the last week (vs. 28% in Germany), hence a better ARPU for mobile publishers.

—  Danish news consumers generously overlap their devices way more than in any country. 79% use a PC, 61% a smartphone and 39% a tablet. Only 24% use only a PC for news. In Japan by contrast, 58% admit using only a PC for their news diet; up there, the use of smartphone and tablet to access information is respectively one half and one third of Denmark.

— In Danish public transportation, smartphones has overtaken print as the main news vector by 69% vs. 21% of the usage.

We all know where to seek inspiration for our digital news strategies.

frederic.filloux@mondaynote.com

Nokia Goes Android – Part II

 

Next week, we might see Nokia’s entry-level feature phones replaced by a low-end device running Android Open Source Project software. The phone may just be a fantasy, but the dilemma facing Nokia’s feature phone business is quite real: Embrace Android or be killed by it. 

Nokia will announce an Android phone! So says the persistent rumor, started about three months ago by an @evleaks tweet, and followed by more details as weeks went by. Initially code-named Normandy, the hypothetical feature phone is now called Nokia X, and it already has its own Wikipedia page and pictures:

Nokia X

Nokia is on the path to being acquired by Microsoft. Why introduce an Android-based phone now? The accepted reasoning is simple…

  • Even though it doesn’t generate much revenue per handset (only $42), Nokia’s feature phone business is huge and must be protected. Nokia’s Form 20-F for 2012 (the 2013 report hasn’t been published, yet) shows its phone numbers compared to the previous year:
    • 35M smartphones (-55%) at an average price (ASP) of $210 (+ 11%)
    • 300M feature phones (-12%) with an ASP of $42 (- 11%)
  • These 300 million feature phones — or “dumbphones” — keep the Nokia flag waving, particularly in developing economies, and they act as an up-ramp towards more profitable smartphones.
  • Lately, dumbphones have become smarter. With the help of Moore’s Law, vigorous competition, and Android Open Source Project (AOSP) software, yesterday’s underfed, spartan feature phones are being displaced by entry-level smartphones. Asha, Nokia’s offering in this category, has been mowed down by low-end Android devices from China.
  • Nokia can’t help but notice that these AOSP-based feature phones act as a gateway drug to the full-blown Android smartphone experience (and much larger profits) offered by competitors such as Samsung, Huawei, and Motorola’s new owner Lenovo.
  • So Nokia drops its over-the-hill Symbian software core, adopts Android, adds its own (and Microsoft’s) services, design expertise, and carrier relationships, and the result is Nokia X, a cleaner, smarter feature phone.

That’s it. Very tactical. Business as usual, only better. Move along, nothing to see.

It’s not that simple.

There’s an important difference between the Android Open Source Project (AOSP), and the full Android environment that’s offered by Samsung, LG, HTC and the like.

The Android Open Source Project is really Open Source, you can download the source code here, modify it as you see fit for your application, add layers of services, substitute parts…anything you like.

Well, almost anything. The one thing you can’t do is slap a figurative “Android Inside” sticker on your device. To do that, you must comply with Google’s strict compatibility requirements that force licensees to bundle Google Mobile (Maps, Gmail, YouTube, etc.) and Google Play (the store for apps and other content). The result isn’t open or free, but smartphone makers who want the Android imprimatur must accept the entire stack.

As an added incentive to stay clean, a “Full Android” licensee cannot also market devices that use a different, incompatible version (or “fork”) of the Android code published by Google. A well-know example of forking is Amazon’s use of Android source code to create the software engine that runs its high-end Kindle Fire tablets. You won’t find a single instance of the word “Android” on these devices: Google won’t license the name for such uses.

(For more on the murky world of Android licensing, bundling, and marketing agreements, see Ben Edelman’s research paper: Secret Ties in Google’s “Open” Android.)

The hypothetical, entry-level Nokia X can’t offer an entire Android stack — it can’t be allowed to compete with the higher-end Lumias powered by Microsoft’s Windows Phone — so it would have to run an “unmentionable” Android fork.

Even without the “Android Inside” label, everyone would soon know the truth about the Android code inside the new device. This could give pause to software developers, carriers, and, the more curious users. “Where is Microsoft going with this? Won’t the Android beast inside soon work its way up the product line and displace the Windows Phone OS?”

Microsoft will make soothing sounds: “Trust us, nothing of the sort will ever happen.  Nokia X is a purely tactical ploy, a placeholder that will give Windows Phone enough time to reveal its full potential.” We know how well attempts to create a Reality Distortion Field have worked for Microsoft’s Post-PC denials.

The Redmond not-so-mobile giant faces a dilemma: Lose the Asha feature phone business to aggressive forked-Android makers, or risk poisoning its Windows Phone business by introducing potentially expansionist Android seeds at the bottom of its handset line.

Several observers (see Charles Arthur’s penetrating Guardian column as an example) have concluded that Microsoft should follow Amazon’s lead and accept the “Come To Android” moment. It should drop Windows Phone and run a familiar Embrace and Extend play: Embrace Android and Extend it with Bing, Nokia’s Here Maps, Office, and other Microsoft properties.

Critics, such as Peter Bright, an energetic Microsoft commenter, contend that forking Android isn’t feasible:

“Android isn’t designed to be forked. With GMS, Google has deliberately designed Android to resist forking. Suggestions that Microsoft scrap its own operating system in favor of such a fork simply betray a lack of understanding of the way Google has built the Android platform.”

Dianne Hackborn, a senior Android engineer (and a former comrade of mine during a previous OS war) contradicts Bright in great point-by-point detail and concludes:

“Actually, I don’t think you have an understanding of how Google has built Android. I have been actively involved in designing and implementing Android since early on, and it was very much designed to be an open-source platform… Android creates a much more equal playing field for others to compete with Google’s services than is provided by the proprietary platforms it is competing with. I also think a good argument can be made that Android’s strategy for addressing today’s need to integrate cloud services into the base platform is an entirely appropriate model for a ‘real’ open-source platform to take.”

In the end, Microsoft probably doesn’t trust Google to refrain from the same games that Microsoft itself knows (too well) how to play. Microsoft used its control of Windows to favor its Office applications. Now it’s Google’s turn. The Mountain View company appears set to kill Microsoft Office, slowly but surely, and using all means available: OS platforms and Cloud services.

None of this draws a pretty picture for Microsoft’s mobile future. Damned if it introduces Android bits at the low end, damned if it lets that same software kill its Asha feature phone business.

JLG@mondaynote.com
@gassee
———————-
PS: Almost four years ago, I wrote a light-hearted piece titled Science Fiction: Nokia goes Android. It was actually less fictional than I let on at the time. In June 2010, I was asked to give a talk at Nokia’s US HQ in White Plains, NY. I was supposed to discuss Apple but I declined to spend too much time on that topic arguing that the Cupertino company was too “foreign” to Nokia’s culture. Instead, I made two suggestions: Fire your CEO and drop your four or five software platforms — Symbian and Linux variants — and adopt Android. Nokia’s combination of industrial design expertise, manufacturing might, and long-standing, globe-spanning carrier relationships could make it a formidable Android smartphone maker.

The first recommendation was warmly received — there was no love for Olli-Pekka Kallasvuo, the accountant cum attorney CEO.

The second was met with indignation: “We can’t lose control of our destiny”. I tried to explain that the loss had already taken place, that too many software platforms were a sure way to get killed at the hands of monomaniacal adversaries.

Three months later Kallasvuo was replaced…by a Microsoft alum who immediately osborned Nokia’s smartphone business by pre-announcing the move to Windows Phone almost a year before the new devices became available.

—–

64 bits. It’s Nothing. You Don’t Need It. And We’ll Have It In 6 Months

 

Apple’s A7 processor, the new iOS 7 and “house” apps are all industry firsts: genuine, shipping 64-bit mobile hardware and software. As we’ve seen before with the iPhone or the iPad, this new volley of Apple products is first met with the customary bursts of premature evaluations and counterfactual dismissals.

On September 10th, Apple revealed that the new iPhone 5s would be powered by its new 64-bit A7 processor. The initial reactions were less than enthused. We were treated to exhumations of lazy bromides…

“I don’t drink Kool-Aid. Never liked the stuff and I think we owe it to ourselves to collectively question whether or not Apple’s ‘reality distortion field’ is in effect when we consider how revolutionary the iPhone 5S is and if Apple’s 64-bit A7 processor under its shiny casing will be all its [sic] cracked up to be when the device hits the market in volume.” [Forbes]

…and equally lazy “markitecture” accusations…

“With current mobile devices and mobile apps, there really is no advantage [to 64 bits] other than marketing — the ability to say you’re the first to have it…” [InfoWorld]

…and breezy brush-offs, such as this tweet from an industry expert:

“We’ll see just how good Apple’s marketing team is trying to leverage 64-bit. 64-bit add more memory and maybe registers. Period.” [Twitter]

Rather than wonder what these commenters were drinking, let’s turn to AnandTech, widely regarded as one of the best online hardware magazines.

Founded by Anand Lal Shimpi when he was all of 14-years-old, AnandTech is known for its exhaustive (and sometimes exhausting) product reviews. The 14-section September 17th iPhone 5S review doesn’t disappoint. Among other things, it provides detailed iPhone 5S vs. iPhone 5 performance comparisons such as this:

5S GeekBench Anand Edited

There are many other charts, comparisons, and considerations of the new 64-bit ARMv8 instruction set, the move from 16 to 32 floating-point NEON 128-bit registers, the hardware acceleration of cryptography operations… It’s a very long read, but not a boring one (at least not for interested geeks).

The bottom line is plain: The A7 processor is a substantial improvement that’s well supported by the 64-bit iOS7. (And I’d like to meet the author and bow to his encyclopedic knowledge.)

Was it because of AnandTech’s cool analysis that the doubters have changed their tune?

As I predicted, Apple A7 benchmarks well due to CPU arch (for IPC), new GPU, ARM v8′

Now that the A7 had become a Benchmarking Beast, the author of the previous week’s brush-off tweet (“more memory and maybe registers. Period”) has revised his position [emphasis mine]:

“The improvements Apple made with the A7 are truly incredible, and they really went against the grain in their choices. With an industry obsessed with more cores, they went with fewer, larger and efficient cores. With people expecting v8 and 64-bit ARM in late 2014, Apple brings it out in 2013 with full Xcode support and many performance optimizations.” [...] “Apple has done it again, but this time in unexpected fashion.”

That all-purpose defense, unexpected, provides a key to the wrong-footing of many “experts”.

When Apple entered the microprocessor field a mere five years ago with its acquisition of Palo Alto Semiconductor, the move was panned: Apple had no future competing with established industry leaders such as Intel, Qualcomm, Nvidia, and Samsung.

But with the successive, increasing refinement of the A4, A5, and A6, the designs were ultimately viewed as good, very good, roughly on par with the rest of the industry. What these processors lacked in raw power was more than made up for by they way they were integrated into Apple’s notion of a purposeful, usable mobile device: Enhanced UI responsiveness, reduced power consumption, obeisance to the unique requirements of media and communications.

The expectation was that Apple would either fail, or produce a “competent” (meaning not particularly interesting) iteration of previous A4-5-6 designs. No one expected that the processor would actually work, with all in-house apps running in 64-bit mode from day one.

But let’s back up and rewrite a bit of history, ourselves:

On September 10th, Samsung announced its flagship 64-bit Exynos processor, supported by Android 5.0, the 64-bit version of Google’s market-leading mobile OS. The new Galaxy S64 smartphone, which will ship on September 20th, features both 64-bit hardware and software components. Samsung and Google receive high praise:

“Supercomputer-class processor… Industry-leading performance… Tightly integrated 64-bit software and hardware open a new era of super high-performance applications previously impossible on mobile devices…”

And Apple gets its just deserts:

“Once again, Apple gets out-innovated…This confirms the trend we’ve seen since Tim Cook took over… iPhones have become second-class devices… The beginning of a long decline…”

Apple can be thankful this is fantasy: The real world would never treat it like this (right?).

My fantasy isn’t without basis: Within 24 hours of Apple’s September announcement, Samsung’s mobile business chief Shin Jong-kyun said his company will have its own 64-bit Exynos processor:

“Not in the shortest time. But yes, our next smartphones will have 64-bit processing functionality…” [The Korea Times]

As for Android support, no problem: 64-bit versions of the underlying Linux kernel already exist. Of course, the system software layer that resides on top of the Linux kernel — the layer that is Android — will also need to be converted to take advantage of the 64-bit processor, as will the Software Development Kit (SDK) that third-party developers use to create apps. It’s a sizable challenge, but one that’s well within the Android’s team skills and resources; the process has certainly been under way for a while already.

The real trouble starts outside of Google. Which 64-bit processor? Intel’s (the company says it will add 64-bit “capabilities” to Android)? Samsung’s? Qualcomm’s?

Who writes and supports device drivers for custom SoC modules? This sounds a lot like Windows device driver complications, but the complexity is multiplied by Google’s significantly weaker control over hardware variants.

Apple’s inherent control over all of the components in its platform will pay dividends in the speed and quality of the transition. There will be glitches — there will always be new, factory-fresh bugs — but the new 64-bit hardware is designed to run existing 32-bit apps, and it seems to actually do so in practice.

Now let’s go beyond the iPhone 5S. In his September 10th presentation, Phil Schiller, Apple’s Marketing Supremo, called the A7’s performance “desktop class”. These words were carefully calibrated, rehearsed, and approved. This isn’t a “Can’t innovate anymore? My asssaeta, blurted while seized by religious fervor at last Spring’s Apple Developers Conference.

Does “desktop class” imply that Apple could use future versions of its 64-bit processor to replace Intel chips in its Mac devices?

In the AnandTech post quoted above, several benchmarks compare Apple’s A7 to a new x86 chip, Intel’s Baytrail, with interesting results:

AnandTech Baytrail A7

So, yes, in theory, a future Apple 64-bit processor could be fast enough to power a Mac.

But let’s consider a 3GHz iMac running a high-end media creation application such as Photoshop or Autodesk. The processor doesn’t want to be constrained by power consumption requirements, it’s optimized for performance (this even ignores the upcoming MacPro and its thermal management prowess).

Can we see a split in the Mac product line? The lower, more mobile end would use Apple’s processors, and the high-end, the no-holds-barred, always plugged to the wall desktop devices would still use x86 chips. With two code bases to maintain ß OS X applications to port? Probably not.

Apple could continue to cannibalize its (and others’) PC business by producing “desktop-class” tablets. Such speculation throws us back to a well-known problem: How do you compose a complex document without a windowing system and a mouse or trackpad pointer?

We’ve seen the trouble with Microsoft’s hybrid PC/tablet, its dual Windows 8 UI which is considered to be “confusing and difficult to learn (especially when used with a keyboard and mouse instead of a touchscreen).”

The best suggestion I’ve seen so far comes from “a veteran design and management surgeon” who calls himself Kontra and proposes An interim solution for iOS ‘multitasking‘ based on a multi-slot clipboard.

If Apple provides a real way to compose complex documents on a future iPad, a solution that normal humans will embrace, then it will capture desktop-class uses and users.

Until such time, Macs and iPads are likely to keep using different processors and different interaction models.

JLG@mondaynote.com