Archive for the 'Apple Browser Ban' Category

On the CMA’s interim report on mobile ecosystems

You might remember that I was part of a small group of 3 UK web developers invited to brief the UK Competition and Markets Authority (i.e., our monopoly regulator) about Apple’s iOS browser monopoly and Progressive Web Apps. Yesterday, the very large interim report was published.

The CMA tweeted

Apple and Google have developed a vice-like grip over how we use mobile phones and we're concerned that it's causing millions of people across the UK to lose out.

Our provisional findings suggest Apple and Google’s substantial market power across mobile operating systems, apps stores and browsers could be negatively affecting consumers. People aren’t seeing the full benefit of innovative new products and services such as cloud gaming and web apps. Our provisional findings also suggest customers could be facing higher prices than they would in a more competitive market. Apple and Google take many decisions on behalf of their users to protect their security and privacy online – in some cases this has an impact on a user’s ability to make their own choices.

The report is gargantuan, and I haven’t read it all yet. It also deals with App/Play Store approval processes, and advertising, but these are aspects of the industry that concern me less than Progressive Web Apps. On PWAs, it’s pretty damning. Here are some choice quotes; emphasis is CMA’s.

Page 226-7:

Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.

we have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition and users from Apple’s WebKit restriction is justified on security grounds

We further consider that the limitation on the feature support that browsers on iOS can offer is likely to be significant. This appears to be particularly the case with respect to supporting web apps.

In addition to potentially harming the functionality of competing browsers within Apple’s ecosystem, we consider that the WebKit restriction may also serve to support Apple’s highly profitable position in the distribution of native apps through its App Store, and in parallel the market power of its operating system… web apps could in principle also serve to undermine the indirect network effects of native app distribution

Page 378-9:

We concluded in Chapter 5 that a significant contributing factor to the market power of Apple and Google in relation to mobile browsers is the restrictions that they – and in particular Apple – are able to place on rival browsers. We have therefore identified a number of potential interventions aimed at removing these restrictions. These interventions are summarised below:

  • Apple does not permit the use of third-party browser engines within its mobile ecosystem – all browsers are required to use its browser engine, WebKit. We have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition or consumers from Apple’s WebKit restriction are justified on security grounds. We are therefore seeking to assess the merits of a requirement for Apple to allow alternative browser engines on iOS, at least for dedicated browser apps. This could be implemented by requiring Apple to permit third-party browser engines to interoperate with its iOS operating system, subject to those browser engines meeting conditions that would address any risks that might arise from a greater choice of browser engines (for example, complying with appropriate quality and security standards).
  • Restrictions on the functionality of all browsers on iOS: as a possible alternative to requiring Apple to allow alternative browser engines, Apple could be required to enable access to specific features for browsers using WebKit on iOS, including supporting web app functionality. This could bring benefits from web apps providing a stronger competitive constraint on the App Store and the Play Store, while also reducing barriers to entry in the supply of new operating systems. We agree that, without appropriate safeguards, there are potential security and privacy risks associated with greater third-party interoperability with the iOS ecosystem.612 We are initially of the view that the costs and security risks associated with requiring access to core functions on the phone, such as push notifications, screen rotation and full screen capability should not be disproportionate.
  • API access for rival browsers: we also have concerns regarding the differences in APIs that are available to Safari and Chrome by comparison with third-party browsers. This could be rectified by a requirement for Apple and Google to ensure that all browsers within a particular mobile ecosystem have access to directly comparable features and functionality through APIs. To the extent that some of the APIs and other functionality may be proprietary or increase costs for Apple and Google, such an intervention would also need to mandate the terms of such interoperability in a way that provides for access on fair and reasonable terms, potentially with guidance about how this would work in practice.

In its responses to our questions, Apple raised a number of concerns that introducing third-party browser engines, or increasing the interoperability of WebKit, could introduce privacy and security risks. Apple submitted that Webkit offers the best level of security, and has cautioned that ‘mandating use of third-party rendering engines on iOS would break the integrated privacy, security, and performance model of iOS devices’. Apple considers that by requiring apps to use WebKit, it is able to address security and privacy issues across all browsers on the iPhone for all iPhone users, quickly and effectively, and that ‘this is especially true when it comes to security vulnerabilities that have to be fixed as soon as possible in order to mitigate potential exploits by bad actors’.

7.73 However, as discussed in Chapter 5, the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines. Further, and as discussed in Chapter 5, other parties have suggested that the impact of a browser engine on overall device security can, to a certain extent be limited.

Digital Markets Unit

The CMA is going to set up a permanent regulatory body called the Digital Markets Unit (DMU). This will have broad powers to enforce a code of conduct and apply interventions on activities by firms that have been given Strategic Market Status (SMS) in relation to activities in the scope of the CMAs Market Study. The DMU is currently operating on a non-statutory basis but it is intended that the government will introduce legislation to put the regime on a statutory basis when legislative time permits.

It is expected that while the DMU can only apply these regulations in the UK that they will cooperate with other regulators and the impacts will be global. Manchester has been picked as the head office of the DMU and they expect to hire 200 full time employees.

Strategic Market Status

In order to be regulated by the DMU a firm must be designated Strategic Market Status (SMS) in at least one digital activity. The test for SMS has three components:

  • The activity must be at its core digital
  • The firm must have substantial and entrenched Market Power arising from this activity that is unlikely to be removed by competition in the short or medium term
  • Must have a strategic position meaning the use of this market power will be particularly widespread or significant

Both iOS and iOS Safari are recommended by the CMA as being designated strategic market status.

What’s next?

If you have opinions or comments, you’re invited to send them by 7 Feb. And, as I’ve seen, they will be listened to. Mine were, and I’m no cleverer than you. The final report is due to be published in June 2022.

Afterword

I just wanted to point out that I’m not an evil shill for Google, Soros or even the Illuminati. I just bought a new Macbook Pro, I greatly respect the Apple WebKit engineers and standards experts I’ve met over the years, and think Apple’s accessibility team is second to none. I just want Apple’s management to set Safari free.

Other news reports and opinions

Set Safari free!

As you may know, every browser on iOS is actually just a branded re-skin of WebKit, the engine that Safari uses, because Apple won’t allow other engines on iOS.

Fred from Scooby Doo with a masked figure and text 'Firefox on iPhone'. Fred removes the mask to reveal the villain headed 'Apple's Safari'. Then the same with Edge on iPhone and Chrome on iPhone.

Supporters of the Apple Browser Ban tend to give one of three reasons (listed here from most ridiculous to most credible):

The web shouldn’t be “app-like”, it’s for documents only

Whatever. (See A Brief History of Web Apps for more on why this is nonsense.)

Privacy and security are protected by not allowing non-Apple code on devices

This doesn’t really make sense when non-Apple apps are allowed on iOS, which can leak data so valuable that Amazon and eBay will pay you to use their apps rather than web. Apple’s most recent zero-day vulnerability was exploited along with a flaw in WebKit, and so left all users exposed because users of other “browsers” are forced to use WebKit. Stuart Langridge has a great post going deeper into Browser choice on Apple’s iOS: privacy and security aspects.

Allowing other rendering engines leads to Chromium taking over the world

This one kind of makes sense. After all, Opera abandoned its Presto engine and Microsoft abandoned Trident, and both went to Chromium. Firefox risks sliding into irrelevance due to inept lack of leadership. If Apple were forced to allow Chrome onto iOS, then domination would be complete!

The interesting predicate of this argument is that Apple intend to keep Safari as the sad, buggy app that they’ve allowed it to wither to, because it has no competition. I emphatically do not want Chromium to win. Quite the opposite: I want Apple to allow the WebKit team to raise its game so there is an *excellent* competitor to Chromium.

WebKit is available on Windows, Linux and more. Safari was once available on Windows, but Apple silently withdrew it. SVP of software Eddy Cue, who reports directly to Tim Cook, wrote in 2013

The reason we lost Safari on Windows is the same reason we are losing Safari on Mac. We didn’t innovate or enhance Safari….We had an amazing start and then stopped innovating… Look at Chrome. They put out releases at least every month while we basically do it once a year.

There is browser choice on MacOS, and 63% of MacOS users remain with Safari (24% use Chrome, 5.6% use Firefox). As everyone who works on browsers knows, a capable browser made by the Operating System’s manufacturer and pre-installed greatly deters users from seeking and installing another. There is no reason to believe it would be different on iOS. (Internet Explorer on Windows isn’t a counter-example; there were much better alternatives, long before Edge came along.)

But let’s set out aspirations higher. Imagine a fantastic Safari on iOS, Mac, Windows and Linux, giving Chrome a run for its money. If anyone can take on Google, Apple can. It has talented WebKit engineers, excellent Standards experts, a colossal marketing budget, and great brand recognition.

If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web. Come on, Apple, set Safari free!

(You could also read my Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps.)

The most inspiring Apple Event announcement

I watched this week’s Apple Event for a while, but there was nothing that interested me; I have a mobile phone which works fine for me, I don’t need a watch and I can’t afford a new computer.

But here’s one Apple event speech I genuinely found really energising. In 2007, Steve Jobs made a bold announcement at Apple’s developer conference, that I still find inspiring today:

Transcript

Now, what about developers? We have been trying to come up with a solution to expand the capabilities of iPhone by allowing developers to write great apps for it, and yet keep the iPhone reliable and secure. And we’ve come up with a very sweet solution. Let me tell you about it.

So, we’ve got an innovative new way to create applications for mobile devices, really innovative, and it’s all based on the fact that iPhone has the full Safari inside. The full Safari engine is inside of iPhone and it gives us tremendous capability, more than there’s ever been in a mobile device to this date, and so you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone!

And these apps can integrate perfectly with iPhone services: they can make a call, they can send an email, they can look up a location on Google Maps. After you write them, you have instant distribution. You don’t have to worry about distribution: just put them on your internet server. And they’re really easy to update: just change the code on your own server, rather than having to go through this really complex update process. They’re secured with the same kind of security you’d use for transactions with Amazon, or a bank, and they run securely on the iPhone so they don’t compromise its reliability or security.

And guess what: there’s no SDK! You’ve got everything you need, if you know how to write apps using the most modern web standards, to write amazing apps for the iPhone today. You can go live on June 29.

On open Operating Systems, Progressive Web Apps live up to this promise; truly cross-platform code that can be responsive to any form factor, using a mature technology with great accessibility (assuming a competent developer), that is secure and sandboxed, that requires no gatekeepers, developer licenses or expensive IDEs. They’ll work on Android, Windows, ChromeOS and Mac.

But 14 years after Jobs had this bold vision for the open web, iOS hasn’t caught up. Apple has imposed a browser ban on iOS. Yes, there are “browsers” called Chrome, Edge, Firefox that can be downloaded from the App Store for iOS–but they only share branding and UI features with their fully-fledged counterparts on open Operating Systems. On iOS, they are all just differently-badged skins for the buggy, hamstrung version of WebKit that Apple ships and occasionally patches for security (often waiting long after WebKit has been fixed before pushing it to consumers).

Apple knows Safari is terrible. SVP of software Eddy Cue, who reports directly to Tim Cook, wrote in 2013

The reason we lost Safari on Windows is the same reason we are losing Safari on Mac. We didn’t innovate or enhance Safari….We had an amazing start and then stopped innovating… Look at Chrome. They put out releases at least every month while we basically do it once a year.

Forcing other iOS “browsers” to skin Safari’s engine rather than use their own more capable engines is a deliberate policy decision. Apple’s App Store guidelines state

Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

Job’s 2007 speech felt like a turning point: a successful, future-facing company really betting on the open web. These days, Apple sells you hardware that they claim will “express your individuality” by choosing one of two brand new colours. But, for the web, choose any colour you want, as long as it’s webkit-black.

Some of us are trying to change this. Earlier this month I was part of a small group invited to brief the UK regulator, the Competition and Marketing Authority, as part of its investigation into

Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store.

You can watch the video of my presentation, and see Stuart Langridge’s slides.

Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps

On 4 March this year, the UK Competition and Markets Authority announced that it is

investigating Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store.

Submissions from the public were invited, so I replied and was invited, with “Clark Kent” (a UK iOS Web-Apps developer who wishes to be anonymous) and Stuart Langridge to brief the CMA in more detail. We were asked to attend for 2 hours, so spoke for one hour, and then took questions.

CMA are happy for our presentations to be published (they’re eager to be seen to be engaging with developers) but asked that the questions be kept private. Suffice it to say that the questioning went over the allocated time, and showed a level of technical understanding of the issues that surpasses many engineers. (The lawyers and economists knew, for example, that iOS browsers are all compelled to use WebKit under the hood, so Chrome/ Firefox/ Edge on iOS share only a name and a UI with their fully-fledged real versions on all other Operating Systems).

Clark’s presentation

Clark talked of how Steve Jobs’ 2007 announcement of apps for iPhone inspired him to use his webdev skills to make iOS web-apps.

you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services … And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today.

Unfortunately, Safari’s bugs made development much more expensive by breaking Indexed DB; breaking scrolling etc. Also, Apple refuses to support Web Bluetooth, so his customers had to purchase expensive iOS-compatible printers for printing receipts, at 11 times the cost of Bluetooth printers. iOS apps can integrate with Bluetooth, however.

He can’t ask his customers to jettison their iPads and buy Android tablets. Neither can he ask them to use an alternative browser, because there isn’t any meaningful choice on iOS. Clark simply wants to be able to make “amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone”, as Jobs promised. He summed up:

All these business costs inevitably get passed onto consumers. Or worse applications simply never get built, due to the increased cost.

From the perspective of software developers there is no browser competition on iOS.

Apple has banned all the other browser engines and Safari’s bugs and missing features means that web-apps struggle to compete with the AppStore. If third party browsers were allowed, with full access to all the APIs that Apple gives Safari, this would provide Apple the incentive to keep pace with the other browsers and give consumers a means of voting with their feet by moving to a competing browser if they fail to do so.

This would then lead to a universal open app development and distribution platform which would substantially reduce development and maintenance costs for a wide range of business and consumer applications. The open web offers an alternative future where the control from corporate intermediaries along with their fees are replaced with consumer choice and the freedom to easily shift from one platform to another. Instead of having to write multiple separate applications for every device, it allows developers to build their application once and have it work on all consumer devices be it desktop, laptop, tablet or phone.

Write once, deploy everywhere, no gatekeepers, no fees. just as Steve Jobs originally promised.

Stuart’s presentation

Stuart examined whether Apple’s assertion that lack of real browser diversity is actually better for consumers’ privacy and security.

My presentation

Here’s my captioned video. Below is the marked-up transcript with links. Note: this submission is my personal opinion and does not represent the opinion of any of my past or present clients or employers.

Transcript and Links

Hi, I’m Bruce Lawson, and I’m here to talk about Progressive Web Apps and iOS. I’ve been mucking around on the web since about 2002, mostly as a consultant working on expanding people’s websites to be truly worldwide, so they’re performant and work with constrained devices and networks in emerging markets. I’m also involved with making websites that are accessible for people with disabilities. And I was on the committee with the British Standards Institution writing BS8878, the British standard for commissioning accessible websites that last year got a rolled into the ISO. And before that, I was deputy for the chief technical officer at Opera software that makes a popular web browser used by about 250 million people worldwide, predominantly in emerging markets.

Most of my customers are in the UK, USA, or Israel, and they’re largely focused on UK and US markets. In the month of June this year, stats counter showed that 30% of all US web traffic was on iOS, 28% windows, 22% Android. And to drill that into just mobile browsers, 57% were iOS and 42% were Android.

In the UK, 30% of people use Windows to browse the web, 27% iOS, 25% Android. And that jells pretty well with stats from the GDS, the government digital services. Their head of front-end, Matt Hobbs, every month tweets some stats. He said that in June, iOS accounted for 44% of traffic, Android 28%. (Although he does note that because you have to opt in to be tracked, it tends to over-represent the mobile browsers). But we can see that in the UK, 50% of traffic is on iOS and 49% is Android.

So, we obviously have to be concerned with iOS as well as Android, Windows, et cetera, and all the different browsers that are available on every non-iOS operating system. And so, I always recommend to my customers that they use the web. After all, that’s what it’s for.

The principle of universality allows the web to work no matter what hardware, software, network connection or language you use, and to handle information of all types and qualities. This principle guides Web technology design

And that was said by Sir Tim Berners-Lee, and his parents were both from Birmingham, as am I. So he’s practically a relative. And with my work in web standards, those principles still hold true for the web standards we make today. So, I wanted to use the web and I wanted to use what’s called a Progressive Web App, which is basically a website plus. It’s a website and it’s web pages, each of which has a URL. It’s built with web technology, but in modern browsers, conforming browsers, it can look and feel more app-like.

In fact, the UK government itself recommends these. Our government writes,

advances in browser technology have made it possible to do things on the mobile web that you could previously only do with native apps. Services that take advantage of these modern browser enhancements are often called mobile web apps or Progressive Web Apps. The user experience of PWAs and a handset is almost identical to a native app, but unlike native apps, PWAs have a single code base that works on the web, like any normal website. A benefit of PWAs over native apps for the government is that there is no need to maintain lots of different operating system versions of the same app. This makes them relatively inexpensive to develop compared to native apps.

And just like government, business likes to reduce costs, and therefore can reduce costs to the end user. Our government goes on to say,

users can choose to install PWAs on any device that supports technology. If a user chooses to install a PWA, they typically take up less space than the equivalent native app.

And this is very important in emerging markets where lower priced phones have lower specifications and less storage space. The government continues,

PWAs cost less than native apps since they need to be only developed once for different platforms. They are also forward compatible with future upgrades to operating systems

And then it lists browsers that do support PWAs, and it lists Apple, Safari and iOS, but this is only partially true. Apple themselves make this claim in their February 2021 submission to the Australian investigation into monopolies. Apple said of PWAs,

Web browsers are used not only as a distribution portal, but also as platforms themselves, hosting progressive web applications that eliminate the need to download a developer’s app through the app store or other means at all

Therefore, Apple is suggesting that PWAs are a viable alternative to the app store. Apple continues,

PWAs are increasingly available for and through mobile based browsers and devices, including on iOs [my emphasis]. PWAs are apps that are built using common web technology like HTML 5, but have the look feel and functionality of a native app

But, as we will see this, isn’t true. PWAs do not have the same functionality as a native app.

Let’s recap about what a PWA actually is. It’s a bit of an umbrella term, but fundamentally it’s a website, but it can install to the home screen of your mobile device, just like a native app. And it can have its own icon defined by the web developer, launch full screen, portrait or landscape, depending up on what the developer chooses, but it lives on the web.

And this is a really important. It’s important for several reasons. Firstly, because it lives on the web, you’re not downloading everything in one go. A native app is like downloading a whole website all at once. A PWA, you download just the shell, and as you navigate around it, it will get any content it doesn’t already have stored from the web server. Another advantage is that means that you have instant publication. The moment you press the button and it goes on your web server, the next person who opens your app on their device will see the new version. Great for security updates and also great for time-sensitive material.

Another great thing is, of course, is that because there’s no app store, no gatekeeper. Smaller shops don’t have to pay the 15 to 30% tax to Google and Apple. And also, for industries that are not compatible with the app stores, such as adult entertainment, gambling, et cetera, it’s a mechanism of giving an app because they can’t use the app store. And PWAs can work offline.

Let’s briefly look at one. I’m here speaking in a personal capacity. I don’t represent any of my clients or employers, so I can’t show you one of their apps, but I took 15 minutes to convert my WordPress blog into a PWA.

Okay, here, I’m using Firefox on Android. Android, unlike iOS, allows not only different badged browsers, but it actually allows that full browser on, so Firefox on Android is using Firefox’s own Gecko engine. Here, Firefox and Android are collaborating and they can tell when a user goes to my website that it is a PWA, and it offers the opportunity to the visitor to add it to the home screen. You can see it says “you can easily add this website to your device’s home screen to have instant access and browse faster with an app-like experience”. As a developer, I didn’t make this and the user doesn’t have to know anything because the operating system and the browser just show this. If the user chooses, they can add to home screen, they can click on the icon, and it will add automatically or else they can drag it themselves to where they want it.

And here, as you can see, it’s now on my Android home screen. There’s a little Firefox icon at the bottom of my logo to tell the user it’s a PWA. Chrome doesn’t do this, but it does also detect that it’s a PWA and offer to add it to the home screen. And as you can see from the screenshot on the right, when they tickle that icon into life, up pops my website full screen, without an address bar, looking like a native app. If however, a user goes to my website in a browser that doesn’t support PWAs, such as UC Web here, they don’t get offered the add to homescreen thing, they just see my website and navigate it as normal. So people with capable browsers get an app like experience, everybody else just gets the website and nobody loses out.

On iOS it’s subtly, but importantly, different.

So on iOS, if you go to my website, you’re not told anything about this being installable. You have to know to click that icon in the bottom bar that I’ve circled in red. And once you’ve done that, then you get the screen on the right. And you just have to know as a user to scroll down, whereupon you’ll see add to home screen there with no instructions or explanation of what’s going to happen. Anyway, once you click that, then you confirm, and finally it’s on the homescreen. And when you press it, it launches full screen without an address bar. But it still, even though it’s much harder to discover this, it still can’t do everything that a native app could do.

This is Echo Pharmacy. It’s a service that I’ve been using during the pandemic. It’s nothing to do with my employers or clients. I’m just a customer. I use it to get my repeat prescriptions, and I used it and it worked really well. And on the confirmation screen, after I’d ordered some more medication, it said, “Hey, why not use our app?” And I thought, well, why would I need an app, because this website has worked perfectly well for me. So I asked on Twitter, I said, “Why does it need me to download the app?” The website allows me to place and track my meds, why clog up my device, because it’s a download, right? Is it for push notifications, because on iOS websites and PWAs cannot send push notifications. And for a pharmacy like this, it’s important for them to say, “It’s 8:00 PM, have you taken this tablet?” Or, “We notice in four days time, you’re going to run out of this medication. Please come back and order.”

And I got a reply from the CTO of Echo Pharmacy saying,

Hey Bruce, you’re right about push notifications, which for some people are preferable to email or SMS reminders. Beyond that our app and website have feature parity,so it’s really just about what you prefer.

In other words, these people at Echo Pharmacy, not only have they got a really great website, but they also have to build an app for iOS just because they want to send push notifications. And, perhaps ironically, given Apple’s insistence that they do all of this for security and privacy, is that if I did choose to install this app, I would also be giving it permission to access my health and fitness data, my contact info, my identifiers sensitive info, financial info, user content, user data and diagnostics. Whereas, if I had push notifications and I were using a PWA, I’d be leaking none of this data.

So, we can see that despite Apple’s claims, I cannot recommend a PWA as being an equal experience an iOS simply here because of push notifications. But it’s not just hurting current business, it’s also holding back future business. A lot of my clients are looking to expand into new markets. The UN has said by the end of this century, 50% of the population of the world will live in these 10 countries. And as you can see, only one of them is a traditional market for a UK business, the US. And it’s obvious why people want to do this. Whereas, the population of the “west”is not increasing, it’s increasing a lot in new markets.

“The Southeast Asian internet economy is expected to reach $200 billion by 2025“, for example, but all countries are not equal in the technological stakes. Here, for example, is the percentage of monthly income that it takes to buy one gigabyte of mobile data. In the UK, for a gigabyte, (not actually that much [data]), it costs me 0.16% of my monthly income. In India, it’s a little bit more at 0.05%. In the states, 0.1%. In Rwanda, where one of my customers is doing great business, it’s 0.5% of monthly income. In Yemen, where I was born, it’s very nearly 16% of monthly income. So, big downloads cost a lot of money, particularly for something like a medication tracking system, which I might use only once every quarter. It’s a heck of a lot to download at these prices.

VisualCapitalist.com say worldwide, the highest average costs for one gigabyte of data is 30,000% more than the cheapest average price. And it’s not just about data costs either. It’s about data speed. Here, for example, in the UK, the average or the median UK speed is 28.51 megabits per second, in the States, it’s 55. In Hong Kong, it’s 112. In Rwanda, it’s 0.81. In Cambodia, it’s 1.29. In India, it’s 4. In Indonesia, it’s 1.88.

So, a big download not only costs potential customers more, but it takes a lot longer. Facebook recognized this when they released their Facebook Lite app. Facebook said

downloading a typical app with 20 megabyte APK can take more than 30 minutes on a 2G network, and the download is likely to fail before completion due to the flaky nature of the network

Twitter released something called Twitter Lite, which is now just everybody’s Twitter. The Lite’s a PWA, and Twitter said

Twitter Lite is network resilient. To reach every person on the planet, we need to reach people on slow and unreliable networks. Twitter Lite is interactive in under five seconds over 3G on most devices. Most of the world is using 2G or 3G networks. A fast initial experience is essential

So, if we could offer PWAs, we would have a competitive advantage over other people, have much faster installation and a much cheaper installation. Penny McLachlan, who works as a product manager at Google said,

A typical Android app size [a native app, in other words], is about 11 megabytes. Web APKs, TWAs, [this is technical speak for a Progressive Web App], are usually in the range of seven to 900 kilobytes

So, only about 10% of the size of an Android app. So, we can see that PWAs is a competitive advantage for people trying to do business in the wider world, because at post-Brexit, global Britain, et cetera.

It’s no coincidence that the majority of the early PWAs that we saw coming out in 2016, 2017 came out of Asia and Africa, and that’s because when people who make websites and web apps use the same devices and the same networks as their consumers, they absolutely understand why PWAs are great.

But, we can’t make a PWA because we have to care about Safari, which is more than 50% of our traffic in our home market. So, what can I advise my clients to do? Well, a lot of them have settled on something called React Native. They can’t afford to have one developer team for Android, one developer team for iOS, and one developer team for web.

If you’re a massive organization such as Google or Amazon, of course you can afford that, but developers ain’t cheap. And three teams is prohibitively expensive for a smaller organization. React Native, which is open source (but stewarded by Facebook), promises that you write once and it works across platforms, where you’re writing in a language called React, and it compiles down to native applications. So you write in React, you press a button, and it squirts out a native Android app and a native iOS app. And it’s pretty good, I guess.

There’s pros and cons, of course. The pros we write just once. Great. The cons. Well, it still emits a native app, so we still have to submit to app stores, and the timing of that is at the whim of the whoever’s moderating the app store, et cetera. It’s still a big download because it’s a native app.

It’s a more complex built process. There’s not a great deal of build to the web. React Native requires lots of moving parts, internally. It’s harder for us to test the functionality because although we write it once, we have to test it on iOS and we had to test it on Android, and Android testing isn’t as simple as iOS because there’s a massive difference between a top-of-the-range Google Pixel device, or the expensive Samsung devices and the kind of no name cheap Android devices you can get in street markets in Bangkok and Jakarta and Mumbai.

And a problem for me, and for one of my clients, is accessibility. Accessibility is making sure that your app or your site can be used by people with disabilities. Apple and Google have done great jobs making iOS and Android accessible, but React Native has some quirks under the hood, which make it much trickier.

One of the reasons for this is that React Native is quite a new technology and the web is a mature technology, and accessibility on the web is pretty much a solved problem. It isn’t solved if developers don’t do the right thing, but Chrome is 98.5% compliant with the W3C guidelines for accessibility. Microsoft Edge is a 100%. Firefox is 94%. Safari is 97%.

But because we’re writing in React and it’s doing magic tricks under the hood, there are holes in its accessibility. Facebook themselves say,

we found that React Native APIs provide strong support for accessibility. However, we also found many core components do not yet fully utilize platform accessibility APIs. Support is missing for some platform specific features.

They say it’s true, that support is missing. But for example, if you have an external keyboard plugged into an Android device, perhaps because you have Parkinson’s, or (like me) you have multiple sclerosis and you prefer to use a keyboard than the tiny little software keyboards. But if you have an external keyboard, you cannot use that keyboard to focus in to enter any information in any input field that’s made with React Native [on Android]. This of, course, is a huge problem.

Facebook has done some effort into writing up all of their accessibility problems. Here, for example, we can see this is a GitHub board with all the issues and I scroll, scroll, scroll, scroll, scroll through them. There is apparently a fix for the inability to focus into any input fields with Android and a keyboard, but we are at the mercy of Facebook’s release schedules here.

So, what could I advise my clients to do? I tend to advise them, go PWA and let’s hope that the CMA make Apple do the right thing. What I would really like to do is say to them, “Okay, just put this notice on your web app. Say: ‘we’d like to send you push notifications, if that’s okay by you. Please download Microsoft Edge, Mozilla Firefox, or Google Chrome on iOS’.”

However, if they do download Edge for iOS, Firefox for iOS, or Chrome for iOS, that’s no help at all because Apple prohibits those browsers using their own more capable engines and they have to use the Safari engine under the hood. So, consumers get no choice at all.