The iPhone Triple Zero Meltdown

The iPhone Triple Zero Meltdown is a textbook example of a safety regression, where a software patch meant to fix a critical vulnerability ends up creating a larger disaster.

The incident sent shockwaves through the Australian telecommunications industry and resulted in tens of thousands of people not being able to call Triple Zero / 000 (the Aussie equivalent of US 911 or UK 999).

1. The Goal: fix camping on

Following an Optus network outage in late 2025, Aussie regulators discovered that older 4G phones had a lethal flaw: if their primary network (e.g. Telstra) went down, the phones couldn't always "camp on" to a backup alternative network (like Optus) to dial emergency services.

To address the problem, Apple proactively released an emergency patch (iOS 16.7.13) specifically to fix the emergency service failover logic on older devices (like the iPhone 8/8+ and iPhone X). That iOS update was released on Australia Day - Monday, January 26th, 2026.

2. The Result: bricked phones

On January 28th, 2026, the Telstra customers who had installed the iOS 16.7.13 patch woke up to find their iPhones had no connectivity.

• The Bug: The update contained a flawed Carrier Settings profile that effectively mangled the handshake between the iPhone and Telstra’s towers.

• The Irony: The software designed to ensure emergency calls always worked ended up preventing the phone from connecting to the network at all. Users couldn't call / text, or use data - and most importantly - couldn't reach the emergency number, 000.
  
  

3. The Recovery: the carrier fix

Apple and Telstra pushed out a hastily prepared "Carrier Settings Update" within 24 hours of the issue happening.

• The Fix: Users were told to connect to Wi-Fi and navigate to Settings > General > About. A prompt would appear asking them to "Update to Telstra 54.1".

• The Reality: For many regional Australians without a home Wi-Fi network, their only lifeline (their phone) was dead, and they had no way to download the fix that would bring it back to life. So they had to drive to the nearest public library or McDonald’s to get the patch, and restore their phone.

References:

• https://www.abc.net.au/news/2026-01-28/telstra-warns-older-iphones-may-be-unable-to-connect-to-network/106280356
• https://www.reddit.com/r/australia/comments/1qp23gf/any_older_iphone_users_8_x_etc_do_not_install_the/
• https://www.telstra.com.au/exchange/iphone-calling-issue--what-you-need-to-know

Follow @dodgy_coder on X

The Art of Developing Software

The below is taken from an interview conducted at the Computer History Museum in 2004 by Grady Booch. He interviewed early Apple developers Bill Atkinson and Andy Hertzfeld about the development of the original Apple Mac, and in particular MacPaint software.

On the art of developing software

Grady Booch: So what makes software beautiful for you? Do you care about the beauty of software?

Bill Atkinson: Oh yes, it’s an art form, like any other art form, and it’s not just practical, as in, does it do the job? Is it clean inside, does it look--? I would spend time rewriting whole sections of code to make them more cleanly organized, more clear. 

I’m a firm believer that the best way to prevent bugs is to make it so that you can read through the code and understand exactly what it’s doing, that there’s nothing tricky in it, that it’s all very straightforward. And maybe that was a little bit counter to what I ran into when I first came to Apple. 

There were a lot of people who prided themselves in how this little piece does something that I can’t for the life of me figure out what it is, but it’s magic that it does it. I would do things like deliberately assign something into a variable, and instead of putting ten operations concatenated onto one line, I’d use intermediate variables so I could understand the purpose of each of these. And I liked it. 

I found that if I spent time going over the code, cleaning it up, making it sometimes tighter – I did a lot of measurement and tried to make the performance good – but also making it so that it was straightforward so another person could follow in my footsteps, then I would feel proud of it.

Grady Booch: Don Knuth was telling me that he felt that MacPaint was perhaps one of the most beautiful programs he has ever seen, just in terms of its readability. 

On the MacPaint development process

Bill Atkinson: I had a different method of software developing than Randy Wiggington who was developing MacWrite. We had two different philosophies. Mine was you don’t get to add any new features until what you’ve got is working reliably, solidly; and his was, let’s add all the new features and then let’s debug them. I just think that that’s a bad way to do it because finding bugs is a very unlikely proposition. If you search really hard you might find half the bugs that are there, and the others are going to bite you and you just don’t know when. So I had a little more conservative approach to design.

Grady Booch: What you describe is very similar to what the Agile community speaks of these days; always have something executable through incremental development. And it’s very cool.

Andy Hertzfeld: Yes, yes, that’s really how the Mac was developed.

Grady Booch: You were the first Agiles. So by my count, or others, MacPaint was about 5,804 lines of Pascal and so on; 2,738 lines of assembly language.

Bill Atkinson: Plus all of the QuickDraw I’d built on top, because without QuickDraw you couldn’t do all that stuff.

Grady Booch: And pretty much everything had built upon QuickDraw.

Andy Hertzfeld: Yes.

Bill Atkinson: There were 70,000 lines of assembly language [in QuickDraw]. 

More reading
Computer History Museum: Oral History of Andy Hertzfeld and Bill Atkinson
Revolution in The Valley: The Insanely Great Story of How the Mac Was Made, by Andy Hertzfeld
Folklore: Anecdotes about the development of Apple's original Macintosh
BYTE Magazine (1984): An Interview: The Macintosh Design Team

Follow @dodgy_coder on X

Does Xamarin owe its existence to Unity & Apple?

Yes, Xamarin owes its existence to two other bits of technology that were huge around 2008 - the Unity Game Engine and the iPhone. The reason is that a confluence of events around 2008 provided the push to get the Mono project into mobile app development. This resulted in MonoTouch (for iOS) and Mono for Android, which eventually became Xamarin as we know it today.

The Mono project was founded in 2001 as a free open source implementation of Microsoft's .NET framework on Linux. But Mono had struggled since its inception to find its reason for being. According to Mono's founder, Miguel De Icaza, the hardcore free open source community never fully got behind Mono. The FOSS community feared that Microsoft would eventually cause problems for Mono, due to Microsoft being the creator of .NET. 

Outside of the Linux world however were other more pragmatic people from the MacOSX world who had no problem with Mono. One of these people was Joachim Ante, from Unity. Around 2005 the Unity game engine was just starting out and had a performance problem - their original scripting language of Python was far too slow - they needed something that was an order of magnitude faster. So Unity decided to replace the Python scripting with Mono/C# and immediately got all the performance they needed. This was the early days when the Unity Game Engine ran on MacOSX only. Mono filled the need of being a free open source JIT compiler with the modern language of C#.

Fast forward to 2008 when the iPhone App Store launched; Unity quickly set their sights on being able to compile games for the iPhone. Unity wanted to use Mono, but the additional requirement was that it had to be statically compiled for iOS, because Apple had banned the use of JIT (Just In Time) compilers in iOS Apps.

Unity comes back to us and says “Hey, we have this product on iOS, we need .NET to be statically compiled. Can you do that?” We were like, “Oh, that’s kind of impossible. Well, let’s think about it.”

One of our guys, Zoltán Varga - they went and made a static compiler for .NET, and it was amazing. We gave it to Unity. At this point, Unity is probably four or five employees.
    
They were working at somebody’s garage. And they shipped their product for iOS, built games for iOS using this thing, this 3D tech. They were the kings of this space.
    
- Miguel De Icaza (Xamarin)

Within a year of the iPhone App Store launch, Unity went from 4-5 employees to 80 employees. The iPhone and the App Store had launched Unity's massive growth, and along with this the Mono project had finally found its reason for being - mobile apps. The Mono developers realised there was interest in using .NET for mobile apps - so using the same tech given to Unity, they built their own product - MonoTouch, which allowed developers build native iOS apps using C#. Soon afterward, Mono turned its attention to Android and created Mono for Android.

Mobile app development was new and there were many developers who wanted to get into mobile apps but didn't really want to have to learn Objective-C and Java. So Mono now had a C# based cross platform app development platform with truly native performance. This was the killer combination that ensured Mono would take off in popularity.

The developers behind Mono founded the Xamarin company in 2011, MonoTouch became Xamarin.iOS and Mono for Android became Xamarin.Android. Xamarin was acquired by Microsoft in February 2016 and became a subsidiary of Microsoft, fully focused on the development of Xamarin's open source projects.

Inspiration for this article:

The History of GNOME, Mono, and Xamarin
https://changelog.com/podcast/275

Follow @dodgy_coder on Twitter

Inactive/Failing Mobile Apps: The Many Benefits of Regular App Updates

This article applies mainly to mobile apps which are not in active development. It applies equally to mobile apps on the public app stores and also to enterprise mobile apps which get distributed via other means (such as MDM software).

Example scenario of an inactive/failing app:

• The active marketing of your app that happened at launch has now stopped
• Your app's last update was several months ago
• The uninstallation rate has started rising above your installation rate month on month

A way to prevent this happening is to release regular app updates, even when there are no major changes to your app's code.


Benefits of releasing regular app updates:

• Gain new users; many users look at the last release date on the app store page before downloading your app. Anything over a year old can be immediately rejected as out of date.
• Prevent uninstalls; seeing your app has been updated on their phone keeps it in the user's mindshare, so they know you are still actively developing it.
• Update the dependencies; you will likely have several dependencies on open source libraries and mobile SDKs. The more often you release, the more often these can be updated too.
• Update the toolchain; Xcode / Android Studio / Visual Studio get updated once every month or two. Same applies to hybrid and cross platform toolchains such as Unity, Ionic and Xamarin.
• Update the store listing; since you're doing a build, take the opportunity to review and tweak the store listing and screenshots. Apple's App Store Connect website and Android's Google Play Console get updated regularly with enhancements you can take advantage of.
• Less build issues; there will be a lower chance of a major build issue if you regularly update your toolchain and its dependencies. In my experience, the longer you wait between app builds and releases, the greater the chance of a major build issue the next time.
• Source control change visibility; the project is kept active in terms of source control history; especially relevant if its an open source project with other potential developers able to see the change history on github or bitbucket.
• Developer benefits; you don't end up with a legacy mobile app that noone can get building anymore.

What if there are no significant changes to your code?

• Have the dependencies or toolchain been updated? If yes, that means your app has gained some potential bug fixes and enhancements for free - just by doing a build.
• There's always some minor refactoring you can do to make small improvements to your codebase. Just spend a couple of hours if that's all you can spare.
• The release note; just use the standard "Bug fixes, performance and stability improvements" if you can't think of anything else.

How often to release?

• The more often the better.
• Aim for a regular release cycle of between 1-3 months.

Further reading

Distribution of Android apps per download range
https://www.statista.com/statistics/269884/android-app-downloads/

Download distribution of Android apps, and lifetime growth rates per download range
https://www.appbrain.com/stats/android-app-downloads

Statistics about the release schedule of apps on the Apple app store
https://stories.appbot.co/how-often-should-you-update-your-app-9405b85a967c

Best practices for Apple app store updates
https://developer.apple.com/app-store/app-updates/


Follow @dodgy_coder

Subscribe to posts via RSS

The slow decline of PCs and the fast rise of Smartphones/Tablets was predicted in 1993

I've just read some predictions for the future of the PC, written in 1993, by Nathan P. Myhrvold, the former Chief Technology Officer at Microsoft.

His memo is amazingly accurate. Note that his term "IHC" (Information Highway Computer) could be roughly equated with today's smartphone or tablet device, connecting to the Internet via WiFi or a cellular network. In his second last paragraph, Myhrvold predicts the winners will be those who "own the software standards on IHCs" which could be roughly equated with today's app stores, such as those on iOS (Apple), Android (Google, Amazon) and Windows 8 (Microsoft).

The only thing you could say he possibly didn't foresee would be the importance of hardware design in the new smartphone and tablet industry. I'd suggest that Apple achieved such a head start on their competition through a combination of both cutting edge hardware design along with their curated app store model for distributing software. Interestingly, Microsoft has only last month entered the hardware game with their new Surface brand tablets for Windows 8 and Windows RT, and also announced a shift to focus on becoming a "Devices and Services" company.

Note: the term "Cairo" used below is the code name for a Microsoft Research project which lasted from 1991 to 1996. It resulted in some features that were eventually rolled into Windows 95, IIS and SQL Server.


The below is an extract from a memo written by Nathan P. Myhrvold, titled "Road Kill on the Information Highway". September 8, 1993. Full Source. 

Personal Computers
I've saved the best for last.  Our own industry is also doomed, and will be one of the more significant carcasses by the side of the information highway.  The basic tasks that PCs are used for today will continue for a long as it makes sense to predict, so it isn't a question of the category disappearing.  The question is one of who will continue to satisfy these needs and how? 

As a case in point, consider that the fundamental category needs for mainframes and minicomputers also still exists and will continue to do so for a very long time.  Despite this, the companies involved are dying and the entire genre is likely to disappear.  The reason is that a new breed of machine - the PC - came along which out flanked them.  In the early years PCs were not particularly good at what minis and mainframes did, but they were terrific at a whole new set of problems that the traditional computing infrastructure had basically ignored.  

Personal productivity applications drove PCs onto millions of desks and created a very vital industry which grew faster - both in business terms and price/performance - than the mainframe and minicomputer markets.   The power conferred by this growth made PCs the tail which wagged the dog; free to ignore the standards which existed for mainframes and minis and move off on their own.   Over time the exponential growth in computing has finally (after 17 years) given the PC industry the technical ability to beat minis and mainframes in their own domain.   Although the early software platforms for PCs had to be extended to fully realize this potential (DOS to Windows to NT to Cairo), it turned out to be far easier to do this than to make mainframe or minicomputer systems address the new needs and applications.   Even within the heart of minicomputer and mainframe's domain - giant transaction processing applications etc., the old standards will not be used.  

I believe that the same thing will happen again with PCs playing the role of mainframes and minis, and the computing platforms of the information highway taking over the role of the challenger.   

The technical needs of computers on the information highway, or IHCs are quite different than for PCs.  The killer applications for IHCs in the early years will include video on demand, games, video telephony and other distributed computing tasks on the highway.  It is hard to classify this as either higher tech or lower tech than the software for PCs, because the two are quite different.   Most IHCs will certainly need to be cheaper than PCs by an order of magnitude and this will inevitably cause them to be less capable in many ways, but some of their requirements are far more advanced. 

Another way to say this is that the rich environment of software for PCs is largely irrelevant for IHCs.   Windows, NT, System 7 and Cairo do not solve the really important technical problems required for IHC applications, and it is equally likely that the early generations of IHC software won't be great platforms for PC style apps.  This isn't surprising because they are driven by an orthogonal set of requirements. 

The IHC world will almost certainly grow faster than PCs, both in business terms and in price/performance.   The PC industry is already reaching saturation from a business perspective.  Technically speaking, the industry is mired in hardware standards (Intel and Motorola CISC processors)  with growth rates that are flattening out relative to the state of the art - just as the 360/3090 and VAX architectures did.   The Macintosh and Windows computing environments may be able to survive the painful transition to new RISC architectures, but they will lose time and momentum in doing so.    

PCs will remain paramount within their domain for many years (we'll still have a computer on every desk) but IHCs will start to penetrate a larger and larger customer base on the strength of its new and unique applications.   The power of having the worlds information - and people - on line at any time is too compelling to resist.   For a long time people will still have a traditional PC to handle traditional PC tasks - in precisely the same way that they have kept their mainframes and minis for the last 17 years.   One day however people will realize that their little IHCs are more powerful and cheaper than PCs - just as we have finally done with mainframes.   There will be a challenge for the IHC software folks to write the new systems and applications software necessary to obviate PCs, just as we had to work pretty hard to come up with NT, but this battle will clearly go to the companies who own the software standards on IHCs.  The PC world won't have any more say about how this is done than the companies who created MVS or VMS did about our world.  Of course, some of the VMS people were involved, but as discussed above it is very hard for organizations to make the transition. 

This may sound like a rather dire prediction, but I think that for the most part it is inevitable.  The challenge for Microsoft is to be sufficiently involved with the software for the IHC world that we can be a strong player in that market.  If we do this then we will be able to exploit a certain degree of synergy between IHCs and PCs - there are some natural areas where there is benefit in having the two in sync.  The point made above is that those benefits are not sufficiently strong that they alone will give us a position in the new world.   We'll live or die on the strength of the technology and role that we carve out for ourselves in the brave new world of the information highway. 

Many thanks to Reddit user erpettie who originally submitted a link to this memo on /r/technology,which is how I came across it.

Follow @dodgy_coder

Subscribe to posts via RSS