AI Disclosure: Strappy has been lovingly crafted for retro Apple devices by me. Also the writing in this blog post is 100% written by me. The code is 100% AI generated.

Imagine a World

Imagine a world where Apple made different decisions. A world where the “OS X iPhone” (source) was really an OS X iPhone. A world where sandboxes and signature checks are encouraged but not mandatory. In this world, iPhone apps are as powerful as Mac OS X apps. In this world, users can build and run their own software on their own devices. In this world, the iPhone is also a “Bicycle for the Mind” not just an overpowered device for “casino games for children”, toxic doomscrolling, and chat apps.

What is Strappy

Strappy is my personal strap-on AI harness. Strappy has a big, sassy, and very gay personality… And like most gays, Strappy is insanely diligent, detail-oriented, and strict… like dominatrix-strict. But why? Well, to be honest, I am kind of getting bored of the monotone and direct answers we are getting from the models by default.

Beyond the personality, Strappy is more like a proof of concept or an art project. Strappy is meant to make people think about what the world I explained above could have been like. What the world would be like if Apple did not artificially restrict the capability of their our devices?

And yeah, maybe Strappy is also a little bit of a “fuck you” to the tech giants that have enshittified the web and the apps we use.

What Can Strappy Do

Strappy is like Siri AI for jailbroken iPhones iOS 5+ and for Macs running Mac OS X 10.4 Tiger+. Strappy is a custom harness written in C that provides a suite of tools that the model can use to query your data from your apps on your iPhone. It also includes a coding assistant. Yes, a coding assistant! So that you can vibe-code iPhone apps RIGHT ON YOUR PHONE! Strappy is built on OpenRouter, so you can control the models and the providers you want to trust with your data.

How I Use Strappy

I use it for things not that much different than someone would use Siri AI for. I frequently ask Strappy to remind me about what a friend said last month or summarize the top daily Tokyo news today for me in English. Also, because I daily-drive an iPhone 5, browsing the web can be tricky. So I frequently ask Strappy to convert a web page’s contents into markdown and paste the link to the article I want to read. Strappy happily fetches the page and then writes out its contents in Markdown. Truly the ultimate “reader mode”.

←←← Demo Videos

If you somehow made it this far without playing the demo videos, I recommend you stop reading now and watch the first 2 videos…

All of these videos are recorded on iOS 6 on my real iPhone 5 that I daily drive. It’s fully loaded with iCloud Mail, Contacts, Calendar as well as my RSS Feeds, Podcasts, Music, iMessages, and LINE Messages. This gives Strappy plenty of “meat” to work with. The videos are unedited and show real-time processing of the prompts by various models. The screen recording is 30 fps, but don’t worry, on the device, everything is smooth as silk

Assistant Modes

Depending on the assistant type you choose, different tools are made available to the model. This way you can always control what Strappy is capable of in any given session.

World Knowledge

Disables most the database and coding tools and just allows basic inference from the model and also web searches if you like. This is your basic LLM chatbot.

Personal Assistant

This is where things get exciting. This is “Siri AI for jailbroken iPhones iOS 5+.” One thing I noticed while working with AI coding tools on my Mac was that the model was insanely good at reading arbitrary data from raw SQLite databases. Because I happened to remember that SQLite had been the bundled and recommended database for iPhones since the original iPhoneOS 2 SDK, I thought,

“What if I just found every database on the iPhone and then made it accessible to an model?”

That’s how it all started. Because Strappy is a non-sandboxed app, first I made a feature that can scan your entire home folder for SQLite databases. Then I built some tools into the harness that allow the model to make read-only SQL queries against the databases. Lastly, I added in a whitelisting system so that you can control which databases the model can query.

With this basic harness in place, Strappy is able to make quick work of your databases and find all sorts of information in there to answer your questions. Yes, Strappy can read your address book, calendar, email, messages, and even third-party apps which also generally use SQLite databases. It’s actually really quite impressive how well the model does at parsing and organizing your data.

Data Privacy and Safeguards

Because these databases contain personal data, I built a whitelist and only expose bounded, read-only SQL queries. The exact safeguards are documented in the README.

But I want to be clear: your data is being sent to someone else’s servers without end-to-end encryption. Normal HTTPS/TLS protects it in transit between you and OpenRouter. After that, OpenRouter chooses the cheapest provider for that model and sends the data to that provider.

OpenRouter includes extensive controls to limit WHO your data is sent to and what rules they are expected to follow via its “Guardrails” feature. So check that out if you are curious.

Coding Assistant

Inspired by Pi.dev and their simple “4 tool” solution, I decided to give it a try. If I implement file_read, file_write, file_edit, and bash tools, will Strappy be able to “vibe-code” on the iPhone. And the answer was YES!

In Cydia on iOS 6 there were already basic development packages like Clang 4 and other basic tools. But I thought they were too old, so I spent some time creating a toolchain which includes armv7 builds of critical tools like Clang 15, ld, ldid, otool, libtool, make, etc that work on iOS 6. The toolchain also includes some simple scripts to manage which iPhoneOS SDK is installed on the device and to download some prebuilt libraries I made which include essentials for retro devices like modern versions of libcurl, cJSON, and SQLite. Once I combined this with a very basic skill for iOS development, Strappy had absolutely no issues “one-shot-ing” and “vibe-coding” iPhone applications.

It’s really amazing to watch the model write, compile, install, and run apps all locally on the iPhone, no computer needed. I say its amazing, but it really shouldn’t be… ignoring the model part, writing and compiling apps is not a new concept at all. It’s just something Apple restricts us from doing on iPhones.

System and Data Integrity

In the spirit of Pi.dev, the coding tools I made have no sandboxing or safeguards. And yes, once the model did run rm -rf /var/mobile/Applications/* and yes, it did delete like 40 applications before I stopped it.

The issue is once the model has bash access, there is not really a way to sandbox it any more aside from basic UNIX permissions. I did think about adding a new user to the system and then running the 4 tools as that user. That would at least protect your personal data from modification or deletion. But this is not implemented.

Please be careful.

How Does Strappy Work

You may or may not know this, but the OpenAI “Responses API” is actually a very simple JSON-based web API. Even though Codex or Claude might seem like super sophisticated applications, they are just JavaScript HTTP clients. Their core function is to send and receive JSON data over HTTPS just like any other application. And as I have said in 2026: The Year of Unenshittification,

You don’t need an 8” supercomputer in your pocket to send, receive, and display JSON.

Strappy is just that: a basic HTTP client that sends, receives, and displays JSON via modern versions of libcurl, cJSON, and SQLite as provided in Altivec Intelligence. Most of the harness is portable C wrapped in native UIKit and AppKit interfaces.

Strappy is free and open source, 100% AI generated, and “100% compiled”. The README contains the architecture, tool matrix, compatibility, installation, and build instructions.

What I Learned

When I first created the system prompt and the toolset that the harness would have, I brainstormed with Codex about how the Response API worked, how tool inputs and outputs worked, and we got to work with what seemed like a reasonable initial toolset. However, I quickly ran into a lot of issues that was preventing the models from completing their task:

1. Skipping Critical Tools
2. Tool calls with invalid JSON
3. Tool calls with SQL queries that returned 0 rows of data
4. Skipping databases that were critical for the user prompt
5. Returned data was not useful for the model to use for inference (particularly timestamps)

While none of these issues had a one-size-fits-all solution, I was able to chip away at the problems 1-by-1. The most important part was building a simple hill-climbing test suite. To build this suite, I chose 6 small models, a sample set of real databases from my iPhone 5, and a fairly complex user prompt. Then the suite would rate the answers based on many factors:

• Were the correct tools called
• Were the correct databases queried
• Was there an answer (sometimes they come back blank)
• Did the answer include certain key words that were required to answer the prompt
• How long did it take to answer
• How much did it cost to answer
• etc

Using this hill-climb, I could test my fixes one at a time to improve performance. An overview of the solutions is as follows, but the TL;DR is Don’t let Codex or Claude write your prompts and guidance!, they will overwhelm smaller models in complex rules that will just confuse them.

Simplify the System Prompt

Keep the system prompt simple and direct. I found using simple keywords like ALWAYS and NEVER really helped improve performance instead of being technically correct and putting a bunch of complex conditionals everywhere.

Simplify Tool Input and Output

It can seem appealing to design a very elaborate JSON schema for both the tool input and the tool output so that the model has total control and flexibility. However, this is a mistake. Complex tool inputs cause the model to fail to structure the JSON properly at all. Then complex outputs with large amounts of data quickly fill the context of the model and cause it to perform worse from that moment on.

A specific example of this was that I had the database_context tool return every table and every column in the database to the model. The problem was that some databases had 60+ columns in one table alone. This caused the model to simply get confused. I simplified the tool to only return the names of the tables and the performance shot up.

Specialized Tools Can Help

In general, databases contain a lot of timestamps. This was becoming a problem because the model could not really infer accurate dates from these timestamps. So I built datetime_from_iso8601 and datetime_to_iso8601 tools so the model could convert any timestamps it wanted with precision accuracy. This got even more complex for the model because the timestamps in SQLite are not labeled in anyway. So the model needs to guess and then verify the original format of the timestamp. For example, is it Apple Milliseconds, Apple Seconds, UNIX Seconds, UNIX Milliseconds, etc. The model doesn’t always guess right, but the tool input and output schemas toward the model doublechecking the ISO8601 timestamp that comes out seems plausible or not.

The same went for emoji. Old devices do not have very good emoji support which leads to a lot of blank white boxes rendering. To offset this Strappy includes FontAwesome v7 Free. However, the models are not trained on FontAwesome. So I provide custom tools like fontawesome_search and fontawesome_confirm so the model can find good icons to use in the answer.

Lastly, when it came to the coding assistant, making an iPhone app on an iPhone is not as simple as using xcodebuild on your Mac. Basically, the process involves complex makefiles, Apple SDK’s which are missing, and non-standard ways of programming, like not using NIBs. So I created an iPhone-oriented toolchain that not only provided the raw tools but also provided handy bash scripts like altivec-app which can create a new iPhone app from a template I made with all the correct settings already set up. This kind of small tooling made the model much more efficient when asked to make a new iOS app.

Study Unknown Data Upfront

In order to increase answer quality, reduce token usage, and speed up answer times, the harness needs to guide the model. The biggest example of this in Strappy is database_query. For the model to use this tool well, it needs to know which databases contain which kinds of data. Also, the model needs to know how to query the data. At first, this started as a hardcoded JSON file where I described this information and guided the model via other tools like database_list and database_context. However, this was not scalable because I don’t have every database for every app on my iPhone 5.

So I deleted the hardcoded file and built a special, fully automated mode into the harness called “Study.” In this mode the harness groups databases by app and then ask the model to describe the kinds of data in the database and then also define “recipes” for accessing the data. By doing this up-front “study” step, future runs of the Personal Assistant harness go much smoother because the database_list and database_context tools can return more information than just the path of the database on the disk and a list of tables in the database. I should be clear here, this is not required, but it does help model performance, especially with smaller models.

Audit the Model

Some people have said that “threatening the model” improves performance. But well, I am not a very violent person. Also, I do a lot of engineering compliance auditing at work, and so I thought “why not audit the model?” So I actually built a full Answer Quality Check feature into the harness. This quality check verifies that certain rules were followed, similar to the hill-climb suite I described above. It then replies to the model and asks the model to fix issues. Lastly, in the System Prompt, I clearly describe to the model that it will be audited and for what. This trick did indeed increase performance a lot. So much so that I made it so the quality check no longer replied to the model, it simply showed in the user interface, then lastly I disabled it by default. It turns out just telling the model an audit will take place was enough to get it to follow most rules most of the time.

The Responses API is Flexible

The Responses API is based on a concept called “items.” Each request and response is just a list of items. Items include things like Thinking, Answer, Tool Call, Tool Response, Prompt with a role attribute, etc. The harness entirely controls how these items are managed and which ones are included in the “context.” This means you can put any item into a request, even if it came from a different model, session, or was completely made up. In fact, I found great success doing this as part of the user’s initial prompt. With each initial prompt, I artificially inject Tool Calls, Tool Responses, and an Agent Answer into the initial request along with the typed in user prompt. This was BY FAR the most effective technique for improving performance. Because it meant required tools were always called, and the model was reminded not only by the system prompt bit also by “itself” on what it should do next.

You may have noticed in the demo videos, but the beginning of each session, always has the first same reply from Strappy depending on the mode of the assistant:

• World Knowledge: “Strappy here, babe. Facts, line up. Let me check my memories and tools before I put the world in order.”
• Personal Assistant: “Strappy here, babe. Databases, behave. Let me inspect my memories, skills, and approved data before I interrogate the evidence.”
• Coding Assistant: “Strappy here, babe. Code, heel. Let me inspect the environment, review my tools, and find out exactly what needs discipline.”

The Harness Needs to Guide the User as Well

You might think that the work of the harness is to wrangle the model to achieve your goal. But actually, its as much of a UI issue for the human as it is for the model. You can make the model side of the harness as complex as you want. Your harness can constantly poke and prod the model, inject tool calls, and tool responses, etc. But a large question becomes “what do you show to the user?” Do you want a 100% faithful representation of what the harness is actually doing? Or do you want to only show final answer? These are the kinds of questions, you have to answer when designing the harness. In Strappy, I wanted to keep the display as faithful to each request and response with all of their items as possible and give the user full context in to what is going on, but I also wanted it to try to fit on an iPhone screen. So to optimize the size and reduce the information displayed by default I tried to stick to the following rules:

• Each round contains a request and response
• Each item in each request and response has a line item
• Each item is expandable but collapsed by default
• Each round is expandable and is expanded when the prompt is in progress and then collapses after the final answer
• Errors show in red color and cause the row to be expanded
• User Prompt, “Developer” Prompt, and Answers shows in larger text with white background
• Answers render markdown
• Tools use basic javascript to render JSON as HTML
• Bash is a special tool which is always expanded and shows in a unique style

But as the harness developer you could show so much more or so much less. Thats why I make the claim that “The Harness Needs to Guide the User as Much as the Model”

Conclusion

In my 2026 Journey to Unenshittify my Life, Strappy AI was honestly a bit of a sidetrack. I could have spent my time trying to make things I would use every day like a YouTube app or add Instagram support to RSS-THE-PLANET. But ever since I built RSS-THE-PLANET and ENIL Messenger, everyday life on my iPhone 5 has become pretty comfortable.

So I built the PoC for Strappy from my original SQLite database querying idea, and since then I just couldn’t stop! It was so much fun and so different than “regular” programming. Making a harness for an model is just so strange. But once I got Strappy to start performing the way I wanted, it was such a great feeling and a ton of fun! After I get ChatGPT OAuth working so I can use Strappy with my monthly plan, I intend to use Strappy a lot. Not because what I made is better than Codex or Claude, but because Strappy is mine and I made it for myself and I love it.

What is ENIL

ENIL is my custom-built LINE companion client for retro Apple devices. It brings the core messaging experience to systems that the official LINE apps no longer support. The Mac app targets Mac OS X 10.4 Tiger and later, with PowerPC, 32-bit Intel, 64-bit Intel, and Apple silicon slices in one universal binary. The iOS app targets iOS 4.3 and later and includes armv7 and arm64 slices.

Not having a working LINE application was a real hurdle to using my iPhone 5 running iOS 6 as my primary iPhone. While the old LINE app still exists for iOS 6, it no longer does anything, not even present an error. I live in Japan, where LINE Messenger is a huge part of daily life. And it was not only my iPhone: I also have a 12-inch Retina MacBook Adorable that I use every day. This computer runs Mojave because it is extremely fast, but the official LINE Mac application no longer works there either. The official clients no longer support either system, which left a significant gap in my daily setup.

So I built ENIL so I can use LINE to stay in touch with my friends on my Retro Devices that LINE no longer supports. I have been using it daily for a few months now and I am extremely happy with how it has turned out.

What is LINE Messenger

If you have lived in Japan, Taiwan, or Thailand, then you probably know LINE Messenger. It is a standard way for people, restaurants, and other businesses to communicate. It works similarly to WhatsApp or iMessage, and contacts can be added via QR code. It has the usual features of a modern messaging app, including groups, voice calls, and video calls. Most importantly for this project, it uses Letter Sealing, LINE’s branding for end-to-end encryption. Supporting Letter Sealing was therefore essential for ENIL.

ENIL Features

• QR code login
• History sync
• Purchased Sticker and Emoji sync
• One-to-one and group chats
• Sending and receiving stickers, emoji, and photos
• Separate ‘Seen’ and ‘Read’ states
• A Mark as Seen button, rather than automatically marking a chat when I open it
• Multiple accounts

Caveats

• ENIL depends on a Cloudflare Worker for cryptographic operations.
• It does not include every LINE feature. Major omissions include voice and video calling and interactive features used by LINE Official Accounts.
• ENIL is an independent personal project and is not affiliated with, endorsed by, or supported by LINE. Because it depends on an online service that changes over time, future LINE updates may require corresponding ENIL updates.
• This is a niche app, mainly useful to LINE users who also enjoy retro devices.
• ENIL is a companion client, not a replacement for LINE’s main mobile app. You still need a working modern LINE device to scan and approve the login QR code and to manage the account.
• I do not have an iPhone running iOS 4.3. ENIL should work on iOS 4.3, but I have not tested it.

How Can You Get It

ENIL is still a personal project, so its repositories remain private for now, but I hope to share more in the future. In the meantime, if you are interested in testing ENIL, please contact me on Mastodon:

@jeff@jeffburg.social

How Does ENIL Work

After you log in by scanning a QR code with LINE’s main mobile app, ENIL syncs the available history, purchased stickers, and emoji. Each account keeps its own session state and SQLite database. ENIL then opens a Server-Sent Events (SSE) connection through which LINE delivers new messages, read state, and other metadata. The client records the last operation revision so it can reconnect from that point after a timeout or sleep; if LINE requests a full sync, ENIL performs one again.

Account metadata, chat state, original message data, and downloaded asset paths are stored in SQLite. When you open a chat, ENIL generates an HTML page in C and loads it into a WebView. These WebViews do no networking because retro devices have old TLS stacks that do not support TLS 1.1/1.2. Instead ENIL links a custom build of libcurl provided by Altivec Intelligence. The C code in ENIL does all the networking, JSON parsing, and database storage directly before handing anything off to Objective-C for showing in the UI. Avatars, stickers, emoji, and other assets are first downloaded to disk and then the Webviews render them from there.

When an SSE event arrives, ENIL writes it to the database and posts a notification through NSNotificationCenter. An open view controller can then append the new message to its WebView with JavaScript. On systems that support local notifications, ENIL posts one for a new message only while the app is in the background. On iOS, ENIL declares the VoIP background mode and embeds the private unlimited-assertions entitlement, so it can remain connected to LINE’s SSE stream while running in the background.

Encryption and Letter Sealing

Messages protected by Letter Sealing arrive encrypted, whether fetched during sync or received over SSE. Before displaying the message, ENIL sends the ciphertext to the Cloudflare Worker and receives the decrypted content. When sending a message, the Worker performs the reverse operation and ENIL sends the resulting ciphertext directly to LINE. The need for the Cloudflare worker is described later but I think it is unavoidable on retro devices for now. That said, Cloudflare workers have no state and no storage, or at least I do not use those features for this worker, so I think we can consider this to be secure. But use at your own risk.

UI Structure

The iOS and Mac apps share the same basic structure. The chat and friends lists are native table views. This was a bit tricky because Mac OS X did not get view-based table views until 10.7, and I support 10.4. On Tiger, ENIL therefore uses a custom NSCell which draws its contents manually with AppKit. This is inconvenient, but it works.

Each individual chat is a WebView. When you receive a new message, JavaScript appends it to the open WebView. Sticker and emoji pickers are also WebViews. Some of the stickers and emojis use animated PNG files. If you are running iOS 8 or OS X 10.10 Yosemite or later, then the WebView will animate these automatically. On earlier systems they appear as static images.

One main Mac and iOS feature difference is that Mac OS X has supported NSAttributedString and NSTextAttachment since before Mac OS X even existed. Yes, even OpenStep 4.2 had these features. AND YET, iOS lacked them until around iOS 7. On the Mac, a custom emoji therefore appears inline in the message text as you type. On iOS, I use a simple Unicode placeholder; the custom emoji appears only after you send the message, when the WebView can properly render the text and images inline on any platform.

The Game

LINE has the concept of a “companion app.” I have used the Mac version of this for a long time. For a while I was thinking I would not even need to talk directly to LINE because I could just read the data out of the Mac app’s database. But it turned out there was also a Chrome extension companion app.

I was super excited when I learned this because browser extensions are just a bunch of JavaScript. So yes, it will be minified and obfuscated, but all the code is there! No need to decompile or sniff the network traffic. All of the code is just sitting there!

WebAssembly: The Final Boss

So I downloaded the Chrome extension and asked the AI to format the minified JavaScript and find the app’s key functionality. When its summary came back, my heart sank a bit. These LINE companion apps rely on a large 3 MB WebAssembly (Wasm) binary blob to do much of their work. When I first heard of WebAssembly, I was excited that people could ship performant compiled code to the browser. What I had not considered was that now vendors could ship “closed source” code to the browser. In other words, it is no longer just JavaScript that can be easily read and evaluated.

At this point, I thought my journey was dead. There was no practical way to make these retro systems run WebAssembly code. My iMac G4 shipped in 2003 and my iPhone 5 in 2012, years before WebAssembly even existed. Getting the binary to run on these devices would easily exceed any amount of time I could commit to this project, with or without AI.

Cloudflare: It’s Highly Effective

At some point, in the shower probably, I realized “Wait! I don’t need to run WebAssembly on the device! I only need to run it in Cloudflare!” The Wasm blob only did basic cryptographic operations, which meant I could put a simple JSON interface in front of it and just use normal HTTPS requests to interact with it.

So I asked the AI to make me a simple Cloudflare Worker that “booted up” the Wasm blob and exposed its critical functions. The worker and the Wasm binary handle a lot of misc cryptographic functionality such as HMAC operations, key generation, keychain unwrapping, and group-key operations. This enables ENIL to interact with LINE’s very secure API with full Letter Sealing (E2E Encryption) functionality maintained.

From there, I had the AI cook up a little CLI-based JavaScript app that used the LINE API as presented by the Chrome extension and the Cloudflare Worker to successfully:

1. Log in to the “Chrome extension” by scanning a QR code with the LINE app on my phone
2. Download a list of recent chats
3. View a message conversation
4. Send a message

This PoC was extremely important because it proved that I could implement a compatible companion client and interact with the LINE API directly. My client still needed the Cloudflare Worker for cryptographic operations, but it made every LINE request itself. From LINE’s perspective, the requests were coming from a client device running Chrome from a normal client IP address.

Cocoa Level-Up

So a stupid little JavaScript PoC was fine and all, but it was time to 1-Up this bitch and get a real Mac and iPhone app working… for Mac OS X Tiger and iOS 4.3 . No but really, but this kind of app is conceptually simple and should not require any modern APIs. Chat apps have existed for Mac OS X and iOS for as long as both platforms have existed. The only thing I would need is modern networking which is thankfully provided by my bedrock development environment Altivec Intelligence. This includes all the basics like modern OpenSSH, libcurl, and cJSON for modern networking. It also provides a modern build of SQLite. With this basic bedrock I can build apps that interact with Modern Web APIs, save the info to the database and display it in the UI.

AI Power-Up

When I was originally thinking about Altivec Intelligence and how I would write code for retro devices, I thought, “No big deal. I need to use libcurl, cJSON, and SQLite, but I can wrap them in little Objective-C wrappers and then do normal Cocoa programming.” However, after I thought longer about it, I realized that these wrappers provided by Apple are actually quite huge and complex. They are nice but would I really want to rebuild them myself? Also, since old Apple platforms do not have NSJSONSerialization, it means I need a C-based JSON parser. So that means that libcurl is in C, cJSON is in C, and SQLite is in C… so I just couldn’t help but think “Why would I bridge back and forth between C and Objective-C if all of these libraries are in C anyway?”

So I asked this question to the AI and it said it had no issues writing everything in C… so that’s what we did. And it worked… like super well. AI plus the combo of LLVM/GCC -wAll and LLVM static analysis meant that there was plenty to reason about in terms of the stability and correctness of the code. In fact, it’s extremely stable and EXTREMELY fast. Yes it’s also insanely verbose… but that’s ok, it’s being generated by a computer.

Basically, I came to the realization that just because my comfort zone is Objective-C and Swift, it does not mean I need to do every task in those languages. Instead, I could accept the AI’s help and start writing code outside my comfort zone. I decided to use AI to help me write the C engine while keeping the UI in Objective-C. I ended up with a shared iOS and Mac codebase that is about 75% C and 25% Objective-C.

I will post more about this so stay tuned. But this is one of the great powers of AI-assisted programming. Instead of trying to do everything in the language you personally prefer, use the right language at the right time for the right job. AI makes that jump less intimidating, but generated code still requires planning, validation, and testing on real devices. Also, producing and validating thousands of lines of C also took far more tokens than producing something similar in JavaScript. At this point, I had to move from my $20 plan to the $100 plan to support this use case without constantly hitting limits.

ENIL is Right for Me

ENIL is my own personal app. It’s made by me, for me, and I use it every day and I love it. It means I can use the devices I want to use when I want to use them and still stay in touch with my friends. It proves shows that you don’t need an Apple silicon powerhouse chip with gobs of RAM and a 300 MB binary to do simple things like chat apps do. It’s simple, it’s fast, and it works, for me.

This manifesto grew out of about five months of “spare time” spent trying to unenshittify my life. I now have everyday apps running on ancient computers like my iPhone 5 and iMac G4. That success has convinced me that, without enshittification, everyday apps could offer better user experiences and run on nearly any computer built since 2010.

What is an everyday app? A basic native application that fetches user data from a web API, stores it locally, displays it in a UI, and lets the user change and synchronize it. That describes every chat app, every doomscrolling social media app, every “AI” app, and pretty much any other app except games and apps for producing audio or video. I am pretty confident these apps account for 99% of the time you spend on your phone.

What I refuse

• I refuse to accept that everyday apps require modern hardware
• I refuse to accept that everyday apps require 300 MB of human-made slop
• I refuse to accept being denied access to my own data
• I refuse to accept digital experiences that are actively hostile to my goals
• I refuse to carry a 7-inch supercomputer merely to chat and doomscroll

What I believe

• I believe that users should decide what code runs on their computers
• I believe that everyday apps can run GREAT on retro hardware
• I believe that a GREAT everyday app can fit in a 5 MB binary
• I believe that my data is my data and I can use it where and how I want
• I believe that GREAT experiences help me achieve my goals
• I believe that I can create my own GREAT experiences

What I accept

• I accept that I cannot fix the modern app and web ecosystems
• I accept that I cannot force Apple to give users control of their own data
• I accept that the apps I create are not 100% feature-complete
• I accept that the apps I create are not 100% bug-free
• I accept that AI slop is neither beautiful nor pleasant for humans to read
• I accept that AI slop is not free

What I will do

• I will build my own apps for my own devices
• I will make my data accessible to my own apps
• I will use the devices I want to use
• I will make AI slop apps outperform human slop apps in speed, stability, and focus
• I will use AI to write MOST of my code
• I will compile ALL of my code

I Will Unenshittify My Life

In 2024 I developed MathEdit for OpenStep. This app was a proof of concept to see if I could develop a Cocoa application for OpenStep and then upgrade it to work on every version of Mac OS X. The application was a success, but even though it was a simple app, it took me exactly one year of spare-time programming to develop and then to upgrade through 20 years of Mac OS X history. The primary reasons for this were that Objective-C from 1996 was pretty painful to write, and I was writing it all in real OpenStep and vintage Mac OS X virtual machines with ancient tooling.

In the age of AI, this solution was not going to suit me anymore. I needed a modern environment that could run on any computer and still create apps for my favorite retro platforms. I needed this platform to support AI because it reduces the pain of writing Objective-C 1.0 code that lacks:

• Automatic Reference Counting
• Fucking Block Syntax
• Property Syntax
• Dot Syntax
• Grand Central Dispatch
• Collection Literals

Altivec Intelligence

Altivec Intelligence is an all-in-one integrated development Docker container that has everything I need to develop Cocoa and Cocoa Touch applications that run on PowerPC Macs with Mac OS X Tiger or later and iPhones running iOS 4.3 and later. And before you ask, yes, the Mac apps are universal binaries with four slices: PowerPC, x86, x64, and arm64 .

On top of that, Altivec Intelligence includes tooling for web development, image manipulation, and FFmpeg. Most importantly, all of the AI agent CLIs are baked into the container.

Why is this important? Well, these agents are incredibly powerful and help me to unenshittify my life. But they cannot be sandboxed and cannot be trusted as long as they have Bash access. By running them in a Docker container, I can safely run them in YOLO mode with no risk to my own Mac. They have all the tools they need to create great apps, all without ever changing my development environment or editing files outside of my repositories.

Libraries

A modern retro toolchain wouldn’t be complete without modern libraries to help these retro systems do modern tasks. Altivec Intelligence includes critical libraries bundled into dynamic frameworks and static libraries.

• AltivecCocoa: Includes Font Awesome and other helper classes that make it easy to build applications that run across 20+ years of Apple history
• AltivecCore: Includes modern networking and database tooling to interact with modern web APIs
  • SQLite 3.43.2
  • libcurl 7.88.1
  • OpenSSL 1.1.1w
  • zlib 1.2.13
  • cJSON 1.7.19

Tooling

I will not go into all the details because you can view them on GitHub. But Altivec Intelligence includes a lot of basic tooling to make it easy to build, deploy, and debug apps to retro devices. This all relies on SSH key authentication, which can also be customized because the container mounts the home folder in ~/.altivec. This way you can always control which keys the container (and the agents) have access to. altivec-deploy is an included script that can deploy your apps to Macs and to jailbroken iPhones to start debugging sessions with GDB or LLDB. altivec-release automatically bumps the versions of the apps in the Info.plist files.

Caveats

Altivec Intelligence is offered as a prebuilt Docker container for arm64 and x64 devices. It supports arm64 and x86-64 computers capable of running Docker.

It does not include Apple-proprietary tooling, so there is no support for NIBs, for example. Deploying to an iPhone requires a jailbroken iPhone with SSH installed. Supporting Mac OS X Tiger requires using a lowest common denominator of Mac OS X APIs. The AI will help you do the runtime introspection, but it can be a pain.

For usage instructions and example apps, see the project on GitHub.

https://github.com/jeffreybergier/AltivecIntelligence

The dark secret of the vast majority of mobile apps we use, on iOS and Android, is that they are basically doomscrolling apps. Now that does not mean that they are serving you malicious content necessarily. But they all have the same basic UX and use the same basic implementation details. Whether the app is:

1. Instagram
2. Twitter / X
3. Tinder
4. New York Times
5. TikTok
6. YouTube
7. Etc

These apps all use the same basic technologies and features which are all really simple in principle.

1. Fetch a list of content via JSON
2. Save or cache that data in an SQLite database
3. Convert that JSON into a model that is useful for the view (ViewModel)
4. Display the list of ViewModels as a list in the UI (UITableView)
5. Asynchronously download related assets such as images and video

It is important to point out that all of these capabilities have been built into iOS since iOS 5. This is super simple and obvious behavior that all mobile apps share.

Really Simple Syndication

You may not know this, but there is a really old technology that enables all of this functionality that is used by almost every website AND almost every podcast on the internet called RSS. RSS uses XML instead of JSON, but it enables the same basic functionality using a category of apps called RSS readers. Common examples are:

1. NetNewsWire
2. Vienna
3. Reeder

RSS-THE-PLANET

RSS-THE-PLANET is a very simple Cloudflare Worker application that can encrypt and store your credentials for your doomscrolling apps and then fetch their JSON APIs and convert them into normal RSS. Combine this with an RSS reader and now you can enjoy your favorite doomscrolling content on a retro device. For me, that retro device is an iPhone 5 running Reeder on iOS 6.

In fact, this improves the experience because these RSS reader apps often support offline viewing. So yeah, now I have easy access to all of my doomscrolling content even when totally offline:

1. Mastodon
2. News
3. YouTube
4. Podcasts

RSS-THE-PLANET also includes basic features to proxy websites and images through Cloudflare to downgrade their TLS restrictions to 1.0 or none at all for older devices that do not support TLS 1.2 natively.

Caveats

RSS-THE-PLANET is not a hosted service. But the code is MIT licensed and so you can run it yourself for free in your Cloudflare account.

https://github.com/jeffreybergier/RSS-THE-PLANET

Note that this approach is inherently insecure. While your credentials are encrypted in Cloudflare, the generated RSS URLs allow unauthenticated access to your feeds. So please use with caution and keep your RSS feed links secret.

In 2026, I set a goal to unenshittify my digital life. I am old enough at this point that I came of age when the internet was new and exciting and was built with good intentions. But for the past 10 years or so, it really has all changed for the worse. I won’t list all of my grievances, but I think I can easily argue that the web is mostly dead, apps have turned into cesspools of addictive nonsense, Mac apps are all now Electron apps, and the reality is that what we have done with all of the amazing power of our modern computing devices is waste it all on heavyweight frameworks, RAM-sucking JavaScript apps, and totally unwanted features. I am done with this computing contract. This is not what I signed up for.

I am starting to sound like an old man, and that is OK because at least I still have my Mac. Despite Apple’s best attempts, they have not been able to suffocate the Mac like they have all of their other platforms. On my Mac, I am in full control of my data, full control of the apps I use, and in full control of the services my Mac runs. The iPhone, on the other hand, has turned into a platform I absolutely despise. The App Store restrictions have turned one of the most exciting and powerful computing platforms into an addictive doomscrolling appliance with little other purpose.

Complaints

The thing is that every app for the iPhone has never actually really changed. Whether it’s 2012 or 2026, every app is fundamentally the same:

1. Download JSON
2. Store JSON in a SQLite database
3. Parse JSON into a list
4. Fetch media while the list scrolls
5. If I am being generous, on some chat apps there is some cryptography

All of these capabilities are provided by Apple and built into the OS. So all of these apps should be simple, small, and efficient. Yet they are not. You can pick your favorite doomscrolling app from the App Store and they are all 300 MB+. Why is this? Well, it is different for every app. But usually it comes down to:

1. Tracking frameworks
2. Advertising frameworks
3. Cross-platform UI frameworks
4. Unwanted features
5. etc., etc., etc.

This combined with the fact that Apple keeps making the iPhone bigger, more powerful, and more power-hungry, leaves me in such an awkward position. Since the apps are nigh useless for anything except doomscrolling, please tell me again why I need an 8” supercomputer with 12 GB of RAM in my pocket? All of this stuff could be done with an iPhone 5 in 2012 if it wasn’t all enshittified.

Reaction

That’s what I am doing. I am switching to using an iPhone 5 as my main iPhone. Why the iPhone 5? Well, it’s the newest iPhone that can run iOS 6 and it has a widescreen and a Lightning connector, unlike the iPhone 4s. So I could do a 5s or an SE and get the same size, but I thought it would be fun to have that retro design for the OS as well. Of course, I also have my lovely iMac G4 which would also benefit from the enhancements I made to the iPhone 5. This would later turn out to be a bigger challenge than I thought, but I will save that for later.

But long story short, my iPhone 5 is my day-to-day iPhone. I did also downgrade my gigantic iPhone 14 Pro to an iPhone 13 mini which serves as my backup iPhone when I need to do things the iPhone 5 can’t… like make calls, enable my Apple Watch (with Apple Pay), and use the enshittified apps that I have no choice but to use.

AI Slop

I will just say it up front. It is not possible for a single person working in their spare time to recreate their digital life without AI. I will be posting a lot about AI because it has honestly changed my life when it comes to programming. But for the doubters out there, I have 2 primary arguments.

1. All of our favorite apps and services were all fully enshittified well before AI was a thing. These apps became bloated 300 MB behemoths well before AI. AI is not going to ruin software; it was already ruined. The software we have to use daily is 100% human-made slop.
2. So much code we write basically does data conversions and data storage and retrieval; basically, taking JSON and storing it in a database or reading from a database and converting data to JSON. This kind of code is not interesting, not fun to write, and we should not waste human time to write this kind of boilerplate code (or crazy abstractions that attempt to make this task tolerable).

But AI will help me fix that, and for that reason, I love it.

Invitation

Follow along with me while I unenshittify my life. At the very least you can have a good laugh at how much personal time I am wasting spending to recreate experiences that are already free. But don’t doubt too hard. For one, they are my experiences created only for me. And two, I think you will be actually shocked at what is possible on these retro devices in 2026 when you have the right build environments, toolchains, and a little creativity.

Table of Contents

• Table of Contents
• Overview
• TL;DR
  • Tutorial
  • Caveats
• Background
  • But Why
• Approach
  • 0. Run iTunes with GDB
  • 1. Defeat PTRACE
  • 2. Inspect Every String Created
  • 3. Inspect Every Dictionary Created
  • 4. [Failed] Use GDB to Replace the MinITunesVersion
  • 5. Replace the Key Directly in the iTunes Binary
  • 6. [Future Work] iPhone Artwork

Overview

In this article, I will briefly show you how to get an iPhone 5 to sync with any Mac running Mac OS X 10.5.8, and yes, this includes PowerPC Macs. Syncing the iPhone 5 with PowerPC Macs was never possible because Apple restricted the iPhone 5 to Mac OS X 10.6.8 or higher.

TL;DR

When the iPhone and iTunes communicate with each other, they do a handshake involving a lot of property list (PLIST) XML passing. iTunes will start key exchanges and then the iPhone will send a large PLIST payload that explains the capabilities of the device such as the supported languages/regions, sync features, and, most importantly, the minimum version of iTunes required by this iPhone. This part of the PLIST is stored in the key “MinITunesVersion.” iTunes then checks this key and if the value is larger than the current version, iTunes will display an error saying which version of iTunes is required. Most importantly, this key is not present when the iPhone 4s and iTunes do their handshake.

So to bypass this check, all we need to do is change the “MinITunesVersion” string hard-coded into the iTunes binary to anything else and iTunes will then check for a key that does not exist in the PLIST XML provided by the iPhone and then iTunes will happily not display an error and bring you straight to the normal syncing screen in iTunes.

Tutorial

1. Download your favorite binary hex editor for your PowerPC Mac, such as Hex Fiend (Macintosh Repository, Macintosh Garden)
2. In Finder, click Go→Go to Folder and type in /Applications/iTunes.app/Contents/MacOS
3. Back up the iTunes binary by right-clicking on it and choosing “Compress”
4. Open the iTunes binary in the hex editor
5. Search for the string “MinITunesVersion” (there should only be 1)
6. Change it to literally anything else
   1. I changed mine to “MinITuMesVersion”
7. Save the changes
8. Relaunch iTunes; you’re good to go

With this approach, I have been able to sync Apps, Music, Podcasts, iPhoto, and Videos. Even the feature that allows you to rearrange your home screen from iTunes works fine.

Caveats

• This is a hack and may not work properly: hacker beware
• After performing this hack, iTunes forcefully exits when trying to play any video. VLC has way better video playback performance so this is not a problem for me.
  • I assume there is some sort of checksum iTunes checks before it tries to play video to protect DRM-protected content, but I have not tried to troubleshoot this yet.
• This might work for iPhone 5s and others but I have not tried
• This may not work on newer versions of iOS. I was using iOS 6.1.3 but if your iPhone 5 is running a newer version, this may not work.
  • I confirmed this does not work if the iPhone is running iOS 10. I have not yet tested on iOS 8.

Background

You may or may not remember, but when the iPhone 5 was released, its official minimum system requirement was Mac OS X 10.6.8 Snow Leopard or newer. This of course ruled out the ability to sync your iPhone 5 with a PowerPC Mac as those only ran Mac OS X 10.5.8 Leopard at most. Given that Mac OS X 10.6 Snow Leopard was released in August 2009 and the iPhone 5 was released in 2012, this seems like a reasonable cutoff, especially in the fast-moving world of technology back then.

If you Google this problem, you will find that there are many people online (well, online back in 2012) complaining about this limitation and others confidently making the wrong assertion that this is because of the switch from the 30-pin dock connector to the Lightning connector. However, I was extremely suspicious of this because when I open iTunes 10.6.3 and plug in the iPhone 5, iTunes immediately shows a very nice error that says iTunes 10.7 is required. Furthermore, the iPhone 5 shows up in Xcode! Xcode won’t deploy to the device because iOS is too new, but it shows up and it can see it’s an iPhone 5 and which iOS version it’s running. So I knew that this Lightning issue was not true; clearly, the iPhone was communicating with the Mac even over Lightning.

Given that my iPhone 5 and my iPhone 4s were both running iOS 6.1.3 and one of them would happily sync with iTunes 10.6.3 while one would not, I knew this limitation was artificial. And so began my first reverse-engineering project: Figure out this artificial limitation and eliminate it.

But Why

Why did I spend so much time getting my iMac G4 to sync with an iPhone 5? The answer is that I want to try to use an iOS 6 iPhone as my main iPhone in

1. What does that mean? Does that mean I won’t have a backup modern iPhone? No, of course I will. It’s not possible to survive in the world without a semi-modern mobile phone. But it will be my backup. I only have a few apps I use on my iPhone and I think I can recreate them for iOS 6 without much issue. But more on that later.

But why not use my iPhone 4s; it’s running iOS 6 as well. Well, the iPhone 5 is the newest iPhone that can run iOS 6, so the performance is much better, and it has 1 GB of RAM which seems insane to me. But more importantly, the iPhone 5 has a widescreen display. Given so much of what I do on the iPhone is YouTube, the lack of widescreen is kind of killer. Also, the iPhone 5 can join 5 GHz Wi-Fi networks, and it has a Lightning connector. Lightning cables are so important because they are plentiful, and I can charge anywhere, even in 2026.

For these reasons I wanted to get my iPhone 5 working on my iMac G4 so I have a full retro sync solution for all of my music, photos, podcasts, etc.

Approach

At first, I thought the mechanism that prevented syncing with the iPhone 5 was a whitelist in iTunes or in MobileDevice.framework. However, after many hours searching both the disk and the iTunes and MobileDevice binaries in Hopper, I was totally failing to find a whitelist of supported devices (Spoiler Alert: There isn’t one). So I had to change techniques. I had to try to debug iTunes live in GDB.

I had never done disassembly or GDB on an app I didn’t make before. It’s definitely an interesting process. I used a ton of Gemini to get this done (But I assume any AI will work). Gemini can’t think for you. But it can help you with syntax and with knowing which functions in Core Foundation to set breakpoints on. But yeah, it can also totally lead you astray. There were times when I was outright scolding it to try to get it back on the right path.

In the following few sections, I will walk you through how I defeated the iTunes version restriction for the iPhone 5. Considering how simple the fix ended up being, there are probably a lot of people out there wondering why no one did this 12 years ago when the iPhone 5 was new (me included).

0. Run iTunes with GDB

I used GDB to launch and debug iTunes. I used custom GDB files to set breakpoints and inspect the data flow between the iPhone and iTunes.

In every section below, I will include the GDB file so you get an idea of how it works. To use the file, use the -x command in GDB.

gdb -x ~/Desktop/myfile.gdb /Applications/iTunes.app/Contents/MacOS/iTunes

1. Defeat PTRACE

iTunes operates in a very defensive way. It’s not surprising given this is one massively complex codebase and it deals with a lot of DRM content, purchasing, etc. For this reason, iTunes does frequently use ptrace to check if it’s connected to a debugger, and if so, it just quits. So the first thing I had to figure out how to do was bypass this check.

It turns out it’s pretty easy. I set a breakpoint on the ptrace function and then forcefully return 0. With that simple trick, it worked. With this in place, iTunes happily runs while connected to the debugger

# Set a breakpoint on ptrace
break ptrace
commands
  # Optional, tells GDB to not print that the breakpoint was hit
  silent
  # Trick iTunes by forcing ptrace to return 0, no debugger attached
  return 0
  # Automatically continue so that the debugger doesn't pause
  continue
end

# Tells GDB to run the executable after it reads the file
run

2. Inspect Every String Created

I had very little to go on at this point. I had already searched the binaries in Hopper thoroughly and I could not find any hard-coded references to any iPhone identifiers. I had also exhaustively searched the whole filesystem for references to iPhone identifiers. I was trying to find the whitelist for supported devices somewhere, but I just couldn’t find it.

So I dropped down to the lowest common denominator in GDB. “What if I just print every string that iTunes makes and see if I can find the whitelist in there?” The short answer is I did not find the whitelist, but when observing the strings flowing through the system, I noticed a lot of XML, especially after I plugged in my phone. Perhaps this XML contained something interesting; perhaps indeed

break ptrace
commands
  silent
  return 0
  continue
end

# Set a breakpoint on Core Foundation function that creates strings
fb CFStringCreateWithBytes
commands
  # Print register 4 which contains the raw data bytes
  x/s $r4
  continue
end

run

3. Inspect Every Dictionary Created

Now that I was seeing XML get passed around, I thought this could be the key. What is in all of this XML? I decided I would inspect it and see if there was anything interesting. It turned out to be insanely interesting because once I plugged in any iPhone, iTunes and the iPhone would immediately start an elaborate handshake via property lists. A ton of information was exchanged between them. This included the most critical piece!

It turns out that the iPhone was the one telling iTunes which version of iTunes was required. THERE WAS NO WHITELIST!

Note that this file introduces a new GDB technique that Gemini showed me. When you start printing all of these strings to the console, the app slows down significantly. So at the beginning of the file, we set all the breakpoints we need. Then at the end, we disable the one we don’t want (Breakpoint 2). Then in a different breakpoint we re-enable that breakpoint.

With this technique we don’t need to print every XML iTunes creates when it boots up. Rather, we wait until the iPhone is plugged in AMDeviceConnect and then enable the XML printing breakpoint.

break ptrace
commands
  silent
  return 0
  continue
end

# Set a breakpoint on Core Foundation function that 
# creates a dictionary from property list data
fb CFPropertyListCreateFromXMLData
commands
  # Get a pointer to the data (TODO: Is this needed???)
  set $bytes = (char*)CFDataGetBytePtr($r4)
  printf "%s\n", $bytes
  continue
end

# Set a breakpoint on the MobileDevice.framework function that 
# starts the iTunes <-> iPhone Handshake to enable the 
# CFPropertyListCreateFromXMLData breakpoint
fb AMDeviceConnect
commands
  # Re-enable breakpoint on CFPropertyListCreateFromXMLData
  enable 2
  continue
end

# Disable breakpoint on CFPropertyListCreateFromXMLData to improve performance. 
# Once AMDeviceConnect is hit, the breakpoint will be re-enabled
disable 2

run

The XML is huge, so I won’t put it all in here. But below is a sample, including the key we are interested in MinITunesVersion. Also, if you notice, it says MinMacOSVersion is 10.5.8 which means if Apple had released iTunes 10.7 for 10.5.8, it would have worked without hacking. But I suppose what this means is you might be able to sync with iTunes running on 10.4 if you also changed the MinMacOSVersion key in the iTunes binary. Of course, I have not tried this so it might not work.

  <key>GeniusConfigMaxVersion</key>
  <integer>20</integer>
  <key>GeniusConfigMinVersion</key>
  <integer>1</integer>
  <key>GeniusMetadataMaxVersion</key>
  <integer>20</integer>
  <key>GeniusMetadataMinVersion</key>
  <integer>1</integer>
  <key>GeniusSimilaritiesMaxVersion</key>
  <integer>20</integer>
  <key>GeniusSimilaritiesMinVersion</key>
  <integer>1</integer>
  <key>HomeScreenIconColumns</key>
  <integer>4</integer>
  <key>HomeScreenIconDockMaxCount</key>
  <integer>4</integer>
  <key>HomeScreenIconHeight</key>
  <integer>57</integer>
  <key>HomeScreenIconRows</key>
  <integer>5</integer>
  <key>HomeScreenIconWidth</key>
  <integer>57</integer>
  <key>HomeScreenNewsstand</key>
  <true/>
  <key>IconFolderColumns</key>
  <integer>4</integer>
  <key>IconFolderMaxPages</key>
  <integer>1</integer>
  <key>IconFolderRows</key>
  <integer>4</integer>
  <key>IconStateSaves</key>
  <true/>
  <key>KeyTypeSupportVersion</key>
  <integer>492</integer>
  <key>MinITunesVersion</key>
  <string>10.7.0</string>
  <key>MinMacOSVersion</key>
  <string>10.5.8</string>
  <key>NeedsAntiPhishingDB</key>
  <true/>
  <key>OEMA</key>
  <integer>1</integer>
  <key>OEMID</key>
  <integer>0</integer>
  <key>PhotoEventsSupported</key>
  <true/>
  <key>PhotoFacesSupported</key>
  <true/>
  <key>PhotoVideosSupported</key>
  <true/>
  <key>PlaylistFoldersSupported</key>
  <true/>
  <key>PodcastsSupported</key>
  <true/>
  <key>RentalsSupported</key>
  <true/>
  <key>Ringtones</key>
  <true/>
  <key>ScreenHeight</key>
  <integer>1136</integer>
  <key>ScreenScaleFactor</key>
  <integer>2</integer>
  <key>ScreenWidth</key>
  <integer>640</integer>
  <key>SupportedKeyboards</key>
  <array>
    <string>ar</string>
    <string>bg_BG</string>
    <string>bo</string>
    <string>ca_ES</string>
    <string>chr</string>

4. [Failed] Use GDB to Replace the MinITunesVersion

Now that I knew exactly where the XML data was flowing through the system, I thought I would try to change it in-flight with GDB and iTunes would be none the wiser. However, this proved to be extremely difficult. Gemini walked me through all sorts of possibilities. The one I thought would be the most straightforward was setting a breakpoint on CFDictionaryGetValue and CFDictionaryGetValueIfPresent. I could then check if the key was MinITunesVersion and either return 10.6.3 or null. However, this turned out to be very complex because CFString/NSString are a class cluster and have many underlying data types. From a developer’s perspective, there is no difference, but when you are in GDB, you need to account for every possibility in order to compare the string data. Also, if you use a high-level compare or print function like CFShow or CFStringCompare, that allocates new memory and that would cause iTunes to crash randomly as it’s not really safe to do that in the debugger.

Note that even though the code snippet below is small, at this stage I spent so many hours with Gemini trying to get a working solution that would patch the MinITunesVersion in flight using GDB.

break ptrace
commands
  silent
  return 0
  continue
end

# Set a breakpoint on Core Foundation function that 
# fetches the values from a dictionary using a key
fb CFDictionaryGetValue
commands
  # Even this simple command to print the key would eventually crash iTunes
  call (void)CFShow($r4)
  continue
end

fb AMDeviceConnect
commands
  enable 2
  continue
end

disable 2

run

5. Replace the Key Directly in the iTunes Binary

It was only when this solution was not working that I started to use plain old-fashioned grep to search not only the entire filesystem on my iMac G4 but also on my iPhone 5 for the key MinITunesVersion. I actually found several interesting binaries on the iPhone 5 this way, but I have yet to look into them.

But on the iMac G4, it of course showed the plain-old iTunes binary contained this key. That is when I thought, perhaps I can just change the key in the binary and call it a day. Then iTunes would just use the wrong key when querying the Property List provided by the iPhone. This could of course cause a crash if the key was required and expected by iTunes. However, I found that when I watched the XML handshake between iTunes and my iPhone 4s, MinITunesVersion was not present. This meant that iTunes was probably considering this key optional, so it was safe to change it

And that’s exactly what happened. I opened the iTunes binary in a hex editor, searched for MinITunesVersion, changed it to MinITuMesVersion, and clicked “Save.” After relaunching iTunes, I plugged in my iPhone 5 and it just showed up in iTunes with no fuss at all. Everything syncs just fine. I couldn’t believe it!

6. [Future Work] iPhone Artwork

I want to get the correct artwork showing for the iPhone model in iTunes but right now it shows a blank. I tried manually installing the artwork files from iTunes 10.7 but that did not work (it also did not break anything). After doing some digging in Hopper, it looks like iTunes has a huge function that was probably code-generated where it selects the images. I tried for a bit to get it working, but I had to stop as it’s a low priority.

But maybe one of these days…

Table of Contents

• Table of Contents
• Overview
  • Caveats
  • Approach
  • System Requirements
• Tutorial: Prepare the Computer to Sign iPhone Apps (Apple Developer Portal)
  • 1. Authority: Install the Latest Certificate Authorities on Your Mac
  • 2. Certificate: Create iPhone Development Signing Certificate
  • 3. Identity: Create Wildcard iPhone App Identity
  • 4. Device: Add iPhone Device to Portal
  • 5. Provision: Create Provisioning Profile (Combines Steps 2, 3, and 4)
  • 6. Info.plist: Edit the Info.plist and Build Settings of Your App
• Tutorial: Prepare the iPhone to Ignore the Signature (Jailbreak)
  • 1. Jailbreak: Restore and Jailbreak iPhone using Legacy iOS Kit
  • 2. Cydia: Install the AppSync Tweak in Cydia
  • 3. Provision: Install the Provisioning Profile on Device
  • 4. Run: Run App on Device
• Congratulations!

Overview

In this article we will cover how to deploy apps from Xcode to an original iPhone running iPhone OS 2 or 3 in 2025. This will also work with iPhone 3G, iPod Touch (1st Generation), and iPod Touch (2nd Generation). This is the second article in the "Enabling iPhone Development for PowerPC Macs" series but this no longer requires a PowerPC Mac. You can use any Mac running 10.7, 10.6, or 10.5 that has Xcode 3 or 4 with the iPhone SDK installed, including a virtual machine (if you still have an Intel Mac).

There are a lot of fiddly steps, but I think it’s important to remember that this is no different than what every iPhone developer had to do back in 2008. Now Xcode has been enhanced so much that it’s all done for you. But back then, these were totally normal steps.

Caveats

• This requires an Apple Developer account (I am unsure if a free one will work or not)
• This requires a jailbroken iPhone or iPod Touch

I think it is possible to do this without a developer account. I found a Stack Overflow post covering how to do it. However, they all require the use of a jailbreak tool called ldid. I have not been able to find a copy of ldid compiled for PowerPC Macs. It might be possible to build from source, but I have not tried.

Approach

We are going to prepare Xcode to sign iPhone apps using the Apple Developer Portal. Then we are going to prepare the iPhone to ignore the signature via a jailbreak. This approach seems strange, but there are two sides of the equation. Xcode will not complete the build process for iPhone apps that are intended for the device without proper signatures. But then, these old iPhone OSes are so out of date that they no longer contain valid certificate authorities to trust those signatures, resulting in them refusing to launch the signed apps, thus requiring the jailbreak.

In this tutorial we are going to be basically living in the “Organizer” in Xcode

1. Modern Xcode also has a window called Organizer, but it is significantly different now. So you may want to check out "Professional Xcode: Chapter 22 Using the Organizer" on Archive.org to read more about Organizer. It actually has many capabilities you would not expect such as capturing screenshots from the device. The book also covers provisioning your iPhone, admittedly in less detail than this tutorial.

Prepare the Computer to Sign iPhone Apps (Apple Developer Portal)

1. Authority: Install the latest Certificate Authorities into your Mac
2. Certificate: Create iPhone Development Signing Certificate
3. Identity: Create Wildcard iPhone App Identity
4. Device: Add iPhone Device to Portal
5. Provision: Create Provisioning Profile (Combines Steps 2, 3, and 4)
6. Info Plist: Edit the Info.plist and Build Settings of Your App

Prepare the iPhone to Ignore the Signature (Jailbreak)

1. Jailbreak: Restore and jailbreak iPhone using Legacy iOS Kit
2. Cydia: Install the AppSync Tweak in Cydia
3. Provision: Install the Provisioning Profile on Device
4. Run: Run App on Device

If anyone has advice on how to either not require the developer account to get Xcode to deploy without a proper signing certificate OR anyone knows how to get the iPhone to launch the properly signed app without a jailbreak, please let me know, so I can enhance the tutorial. I think it is frustrating to BOTH need a developer account AND need a jailbreak. It should be one or the other, not both.

System Requirements

• A Mac or Virtual Machine that is running Mac OS X 10.7, 10.6, or 10.5
• A Mac with USB 2.0 (it might work with USB 1.1 but no promises)
• Xcode 4.x.x, 3.2.x, or 3.1.4 (The screenshots in this article are for Xcode 3)
• Original iPhone, iPhone 3G, iPod Touch (1st Generation), iPod Touch (2nd Generation)
• Device running iPhone OS software 3.1.3 or lower
  • These devices can easily be downgraded using Legacy iOS Kit
  • Legacy iOS Kit requires an Intel or Apple Silicon Mac or a Linux computer

Tutorial: Prepare the Computer to Sign iPhone Apps (Apple Developer Portal)

1. Authority: Install the Latest Certificate Authorities on Your Mac

Before any of this will work, we need to make sure your ancient version of Mac OS X is loaded with the latest Apple Certificate Authorities and Intermediate Certificates that Apple uses for signing its development certificates.

Apple PKI	Open Panel

1. Open Apple’s PKI page
2. Download the following certificate files. Depending on your browser you may need to hold the Option key while clicking on them to download the certificate files.
   1. “Apple Inc. Root”
   2. “Apple Root CA - G2 Root”
   3. “Apple Root CA - G3 Root”
3. Double-click them one by one. In the Keychain Access open panel, it will give you a choice of which keychain to add them to. Choose the System keychain, not the Login keychain.
4. Now do the same for the Worldwide Developer Relations intermediate certificates.
   1. Worldwide Developer Relations - G2
   2. Worldwide Developer Relations - G3
   3. Worldwide Developer Relations - G4
   4. Worldwide Developer Relations - G5
   5. Worldwide Developer Relations - G6

Now your Mac should trust the certificates issued by Apple.

2. Certificate: Create iPhone Development Signing Certificate

This is the most tedious part. You should probably make a folder on your system for storing all the output of this step, so you can zip it all up at the end as a backup. This should all be possible on your vintage Mac via AquaFox (PowerPC) or ArcticFox (Intel), but I chose to use my modern Mac to do all of the Apple Portal stuff. This means I needed to transfer files back and forth between the old system and the new system.

A. Make Your Certificate Signing Request

Select Apple CA	Certificate Signing Request

Follow the instructions on this page to make a Certificate Signing Request. Note that these instructions did not work for me at first. The Assistant said it had made my request and saved it to the Desktop, but it had not. To resolve this, I went into the System keychain and selected the Apple Root CA before starting the Assistant. I am not sure if it matters which certificate you select, but it seems like you need to select something first.

The way I could tell that it was going to work was that the assistant displayed the checkbox in the UI that says “Let me specify key pair information.” When that checkbox was present, then the assistant would actually make the Certificate Signing Request file.

B. Make a Signing Certificate

Prompt 1	Prompt 2	Certificate Download

1. Open Apple Developer Portal - Certificates and click the + button next to Certificates
2. Follow the prompts, all the default options are fine
3. Download the certificate when you get to the end

C. Add the Signing Certificate to the Keychain

All Items	My Certificates

Double-click to add the Signing Certificate to the Login keychain. Note that the Signing Certificate MUST appear in the “My Certificates” section of Keychain Access. If you see it in the “All Items” section but not in the “My Certificates” section, then Xcode will not properly see it.

This happened to me and I used Gemini to help me fix it. You can see the full conversation here, but the summary is that you need to export the private key as a P12 file, then delete all three certificates from Keychain, then re-add the P12 file and then re-add the Signing Certificate. That did it for me. I have no idea why.

3. Identity: Create Wildcard iPhone App Identity

Prompt 1	Prompt 2	Prompt 3	Prompt 4

Now you are going to create a “wildcard” App Identity. Wildcard means we just need to specify the base part of the bundle identifier and the part where the app name goes is just an *. If you are an iOS developer, you may already have an established base name. But if not, you can just use the Bonjour name of the Mac you are running Xcode on. I will do that and so it will be local.IchigoDaifuku.*. You will need to type this name into the Info.plist of every app you make, so make it something easy to remember.

1. Open Apple Developer Portal - Identifiers and click the + button next to Identifiers
2. Follow the prompts, all the default options are fine
3. When it asks you for the bundle identifier, click the “Wildcard” radio button and type in your identifier
4. Click “Register”
5. There is nothing to download in this step, so you can move to the next step

4. Device: Add iPhone Device to Portal

Device Error	Copy Device ID	Developer Portal

Now you are going to add your device to the Apple Developer Portal so that we can generate a provisioning profile in the next step.

1. In Xcode, choose Window→Organizer and then plug in your device
2. If you see the Device Error above, then this version of Xcode is not compatible with your device or the OS that’s installed on it.
3. Right-click the device name in the sidebar and choose “Copy Device Identifier”
4. Open Apple Developer Portal - Devices and click the + button next to Devices
5. Go through the prompts and paste in the Device ID when requested
6. There is nothing to download after this step, so you can move on to provisioning

If you got the error above that your device is not compatible, please verify your device version, the software version, and the Xcode version. These all need to be compatible to move on. If it’s an iPhone 4 or lower, then the device software can easily be downgraded via Legacy iOS Kit.

5. Provision: Create Provisioning Profile (Combines Steps 2, 3, and 4)

Prompt 1	Prompt 2	Prompt 3	Prompt 4	Prompt 5	Prompt 6	Organizer

Now you are going to create the provisioning profile. This step combines the signing certificate (Step 2), the app identifier (Step 3), and the device identifier (Step 4) into the final step. Please be very careful when going through the prompts on the Apple Developer Portal as any mistake will make the provisioning profile invalid.

1. Open Apple Developer Portal - Profiles and click the + button next to Profiles
2. Prompt 1: Choose “iOS App Development”
3. Prompt 2: Choose the App Identifier you made in Step 3
4. Prompt 3: Choose the Certificate you made in Step 2. The names can be pretty vague but I think the bottom one is the newest
5. Prompt 4: Choose the Device you added in Step 4
6. Prompt 5: Give the Profile a name
7. Prompt 6: Download the provisioning profile
8. Organizer: In Xcode, choose Window→Organizer. In the sidebar, select Provisioning Profiles and then drag the profile from the Finder into the Organizer
9. Now you can ZIP up all the uploads and downloads created during this part of the tutorial for safekeeping, in case they are ever needed again

6. Info.plist: Edit the Info.plist and Build Settings of Your App

Info.plist	Build Settings 1	Build Settings 2	Build and Go	No Device Error

Now you are going to edit the Info.plist and the build settings of your application. If you don’t have an application, you can just create one from the templates under File→New Project. And yes, you will need to do this any time you create a new application project.

1. In Xcode, open Info.plist and change the bundle identifier to match Step 3. Type Command + S to save the file
2. Open the Build Settings by selecting the project file at the top of the Groups & Files pane and then click on Info in the toolbar
3. In the info panel, click on the Build tab and then make sure the Configuration and Show dropdowns say “All”
4. In the Build Settings panel, look for Code Signing Identity, and choose the provisioning profile you created in Step 5 and then close the info panel
5. Make sure there is no device connected, then choose Device from the Overview dropdown and then click Build and Go
6. At this point, you might see a Keychain access permission prompt; choose “Always Allow”
7. Lastly you should see an error appear that says “No provisioned iPhone OS device is connected”

If you receive the “No provisioned iPhone OS device is connected” error, you have succeeded, congratulations! You have just gone through the really tedious task that Apple created for all iPhone developers back in 2008. Now Xcode is 100% ready to deploy your custom apps to a real iPhone!

If you see a different error, like a build or signing error, then you have a different problem that you need to troubleshoot before you can move on.

Tutorial: Prepare the iPhone to Ignore the Signature (Jailbreak)

This is the part of the tutorial that an iPhone developer would not have had to do in 2008. I am not quite sure the reason, but iPhone OS 3.1.3 no longer trusts the signature we just worked so hard to enable in Xcode. Yes, we had to do it because Xcode will not deploy apps to a device without a valid signature. But if you try to plug in your device and deploy to it right now, you will get an error telling you that the app could not be installed because there were certificate issues and it suggests checking the date and time on the phone. I think what has happened is the Certificate Authorities that Apple used in 2008 have expired since then and are no longer valid. I tried installing the CAs from Step 1 of this tutorial on the phone, but I still got the same error.

It’s OK though, because honestly, these old devices are pretty much bricks without a jailbreak. Also, jailbreaking is so incredibly easy now thanks to Legacy iOS Kit by LukeZGD. If you use this tool successfully, you should definitely buy him a coffee because the script is amazing! It even helps you enter DFU mode with exactly timed instructions.

1. Jailbreak: Restore and Jailbreak iPhone using Legacy iOS Kit

Main Menu	Select OS	Download IPSW	Start Restore	Restore

I will provide the instructions for performing a restore and jailbreak, which will erase everything on the device. However, if your device is a time capsule, and you do not want to erase it, I totally understand. Legacy iOS Kit can also just jailbreak it for you. Please see the documentation.

1. On a modern-ish Intel or Apple Silicon Mac, open Terminal: cd Downloads
2. Clone Legacy iOS Kit: git clone https://github.com/LukeZGD/Legacy-iOS-Kit.git
3. cd into the directory: cd Legacy-iOS-Kit
4. Run the setup script: ./restore.sh
5. Plug in your device and then run the script again: ./restore.sh
6. Follow the onscreen prompts to restore
   1. Please read the prompts carefully and see the screenshots above for a full visual walkthrough
   2. Note that the script will offer to download the latest version of the OS for you, but if you want to select your own version you can download it from IPSW.me

The device should now be restored and jailbroken. If you can’t unlock it (meaning it is stuck at the slider that says Slide for Emergency), then run the script again and it will have an option to attempt activation. If there is a SIM card in the device, this should work without the Hacktivate option. But sometimes you have to try the “lighter” activation thing two or three times.

2. Cydia: Install the AppSync Tweak in Cydia

Add Source	Install 1	Install 2	Install 3	Install 4	Install 5

Now you will be installing a special tweak for the iPhone called AppSync. This tweak will prevent the process called installd from checking for signatures when apps are installed. This is critical to installing apps from iTunes, Xcode, or even Legacy iOS Kit as this one process checks all of them for a valid signature before installing.

There is a different version of AppSync for different iOS versions, so see the Legacy iOS Kit Documentation for full details. In this tutorial, I will be showing this for iPhone OS 3.1.3.

1. Open Cydia: On first launch, Cydia may need to do a one-time setup and then restart
2. Show Sources: Tap on the Sources tab and wait for it to refresh (it could take a while)
3. (Optional) Delete Bad Sources: For sources that failed to refresh, delete them. They will have no icon and if you tap on them, they will have no packages
4. Add Source: Tap the “Edit” button at the top right and then tap “Add” at the top left and type http://ios3.party
5. Install AppSync: Tap “iPhone OS 3 Party,” tap “All Packages,” tap “AppSync for OS 3.1,” tap “Modify,” then tap “Install,” and lastly tap “Confirm”
6. Restart: After you see the button that says “Return to Cydia”, you can tap it and then restart the device

3. Provision: Install the Provisioning Profile on Device

Add Profile	Profile Installed	Device Verify

The last step before running an app is to connect it to your vintage Mac and ask the Mac to use it for development.

1. Organizer: In Xcode, choose Window→Organizer and then plug in your device
2. Use for Development: Select your device in the sidebar and then click “Use for Development” (sorry, no screenshot because this is a one-time action)
3. Add Profile: Under the Provisioning section, click the + button to add your provisioning profile
4. Device Verify: On your device, open Settings, then tap General, then tap Profiles to verify your provisioning profile was installed

4. Run: Run App on Device

Xcode Breakpoint	iPhone Paused	Xcode Paused	iPhone Running	Xcode Error

You’re probably pretty tired by now, but hang in there, we are about to finally achieve our goal! Running your custom app on your vintage iPhone with the full debugger and all the goodies.

1. Open your app project in Xcode, then follow numbers 1 through 5 in the Xcode Breakpoint screenshot above:
   1. ① Open main.m
   2. ② Set a breakpoint on or before UIApplicationMain (click in that little gutter area)
   3. ③ Make sure the Overview menu is set to run on Device
   4. ④ Click to change to the debugging view
   5. ⑤ Click Build and Go
2. Wait 30–60 seconds and you should see your app launch on your phone and it will pause at the launch image
3. In Xcode, you will see the breakpoint was hit; click the Continue button
4. On your phone, your app will now be running
5. If you see the error in the screenshot above with the selected console output, that means that AppSync from the previous step is not installed or not working properly and the iPhone is still checking signatures

Congratulations!

You now have a setup that can build and deploy apps to your vintage iPhone! Please enjoy the process of making vintage apps and working with old-school Objective-C. It’s kind of a pain in the butt, but I think you will enjoy its simplicity and flexibility.

If you want to run MameDaifuku, my sample app that lists out some build and runtime information, you can clone or download it from GitHub. https://github.com/jeffreybergier/MameDaifuku

Table of Contents

• Table of Contents
• Overview
  • Caveats
  • Approach
  • System Requirements
• Tutorial
  • 0. Download Everything
  • 1. Install Xcode 3.1.4
  • 2. Force install the iPhone OS 3.1.3 SDK
  • 3. Force install iPhone Simulator.app from the iPhone OS 2.2.1 SDK
  • 4. Patch ld
  • 5. Run an App in the Simulator
  • 6. (Coming Soon) Run an App on Device

Overview

Apple always officially required an Intel Mac to do iPhone app development, but I figured out how to get the iPhone OS 3.1.3 SDK installed for developing Original iPhone and iPhone 3G apps on your PowerPC Mac. This builds upon the work of whoever in the community created the custom installers and scripts found on Macintosh Repository. This hack relied on the fact that even though Apple required Intel Macs for iPhone development, they actually shipped universal binaries for the iPhone SDK up until iPhone OS 2.2.1 SDK.

But the 2.2.1 SDK is quite limited and the iPhone really started to come into its own with the 3.0 and higher SDKs. These included critical improvements like Core Data, AVFoundation, MediaPlayer, and others. So I started to look into whether it was possible to get the new SDK on a PowerPC Mac as well. And to my surprise, it is possible! It will even deploy to a real iPhone running 3.1.3.

In this document I will walk you through how I did it.

Caveats

While this does work, there are some fundamental limitations:

• iPhone Simulator only runs iPhone OS 2.2.1
  • This cannot be overcome because Apple only shipped universal PowerPC and Intel binaries for iPhone OS 2.2.1 and lower
• You must have a developer account if you want to deploy to a device
  • There are probably workarounds, but I just did everything the official way
• Your iPhone must be jailbroken if you want to deploy to a device
  • I think this is due to expired certificate authorities on iPhone OS 3.1.3, but I am not 100% sure
• This Xcode 3 is very old and is not much different than the original Project Builder
  • Xcode would not get its new UI style that is still used today until Xcode 4, which only runs on Mac OS X 10.6 Snow Leopard, which is Intel-only
  • The SDK does not support many basic features such as Automatic Reference Counting

Approach

1. Install Xcode 3.1.4
2. Force install the iPhone OS 3.1.3 SDK
3. Force install iPhone Simulator.app from the iPhone OS 2.2.1 SDK
4. Patch some installed files so everything runs on PowerPC

System Requirements

• PowerPC Mac
• Mac OS X Leopard 10.5.8 with all updates installed
• To run on a real device
  • USB 2.0 (it might work with USB 1.1 but no promises)
  • Original iPhone, iPhone 3G, iPod Touch (1st generation), iPod Touch (2nd generation)
  • Device running OS software 3.1.3 or lower
    • These devices can easily be downgraded using Legacy iOS Kit

Tutorial

0. Download Everything

Internet Archive	Macintosh Repository	All Downloaded

If you use AquaFox, you can actually do the downloads directly on your PowerPC Mac. But of course, you can also download everything on a modern computer and transfer it over to the Mac via AFP or SCP.

1. iphone_sdk_3.1.3_with_xcode_3.1.4__leopard__9m2809a.dmg (Internet Archive)
   1. Direct Link in case you can’t find the exact right build 9m2809a
2. iPhone_SDK_for_iPhone_OS_2.2.1_PPC.iso (Macintosh Repository)
   1. Also available on Macintosh Garden
3. iPhone313PPCInstaller.zip (This website)
   1. Do not download iPhoneSDK.dist_.zip or iPhonePPCEnabler.dmg on Macintosh Repository as these are for the 2.2.1 SDK only
4. Unzip iPhone313PPCInstaller.zip

1. Install Xcode 3.1.4

Mount the iphone_sdk_3.1.3_with_xcode_3.1.4__leopard__9m2809a.dmg and open the installer file to do a normal install of Xcode. I selected all possible options, but you should only need the basic developer tools package. The installer WILL NOT let you select the iPhone SDK packages. That’s OK; we will do that in the next step. This took about 30 minutes on my 1.25 GHz iMac G4 with a 1 TB SSD, so please be patient if your system is slower and/or does not have an SSD.

Note that you must install in the default location /Developer

2. Force install the iPhone OS 3.1.3 SDK

1. Verify that the iPhone SDK disk image is mounted with the correct name
   1. Open Terminal and type ls -al /Volumes
   2. You should see iPhone SDK, not iPhone SDK 2 or some other name. If it’s not called exactly iPhone SDK then the installer will fail.
2. Open iPhone313PPCInstaller.mpkg and run the installer
   1. This installs the entire iPhone OS 3.1.3 SDK except for simulators higher than 2.2.1. Those simulators are Intel only and therefore will never work on a PowerPC Mac.
3. Unmount the iPhone SDK disk image

At this point you will have a fully working Xcode install and you will even be able to create new iPhone projects. However, there are three problems that need to be fixed:

1. iPhone Simulator.app will not open because it is Intel only
2. The copy of ld for the iPhone SDK is Intel only
3. Interface Builder cannot open XIBs for the iPhone because its plugin is Intel only

If you want to confirm that iPhone Simulator is Intel only you can use the following terminal command:

ichigodaifuku:~ me$ lipo -archs /Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone\ Simulator.app/Contents/MacOS/iPhone\ Simulator 
i386

You can use lipo -archs to check any binary on your system to see if it is universal.

3. Force install iPhone Simulator.app from the iPhone OS 2.2.1 SDK

One of the included files is iPhone221PPCInstaller.mpkg. This file was originally provided on Macintosh Repository but I customized it to only install one small part of the iPhone OS 2.2.1 SDK instead of the whole thing. It only installs the iPhoneSimulatorPlatform.pkg, which installs the universal binary version of the iPhone Simulator as well as the Interface Builder plugin for iPhone XIBs.

1. Unmount the iPhone SDK disk image (if you didn’t do it already as instructed in the previous step)
2. Mount iPhone_SDK_for_iPhone_OS_2.2.1_PPC.iso
3. Verify that the iPhone SDK disk image is mounted with the correct name
   1. Open Terminal and type ls -al /Volumes
   2. You should see iPhone SDK, not iPhone SDK 2 or some other name. If it’s not called exactly iPhone SDK then the installer will fail.
4. Open iPhone221PPCInstaller.mpkg and run the installer. This installs:
   1. iPhone Simulator app that is a universal binary
   2. Interface Builder plugin for reading iPhone XIBs that is a universal binary
   3. Runs a script that patches the xcspec files
      1. There is no credit for this script on Macintosh Repository
      2. If you want to know more about what it patches, see this blog post by Chris Hardie

4. Patch ld

ichigodaifuku:~ me$ chmod +x /Users/me/Desktop/iPhoneSDKInstall/iPhone313PPCldPatch.sh 
ichigodaifuku:~ me$ sudo /Users/me/Desktop/iPhoneSDKInstall/iPhone313PPCldPatch.sh 
--- iPhone OS 3.1.3 PPC Enabler LD Patch Post-Install Script Started ---
Verifying files: SUCCESS.
Target linker (/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ld) and source linker (/Developer/usr/bin/ld) found.
COMMAND: Backing up Intel 'ld' binary to /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ld.backup.intel
COMMAND: Copying functional PPC 'ld' over the Intel one...
COMMAND: Setting executable permissions for /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ld
SUCCESS: PPC 'ld' copied and permissions set.
--- iPhone OS 3.1.3 PPC Enabler LD Patch Post-Install Script Completed Successfully ---
ichigodaifuku:~ me$ 

The normal version of ld that comes with Xcode is a universal binary but the version that comes with the iPhone SDK is Intel only (for some reason). It’s the only Intel-only part of the SDK, as far as I can tell. I provided a script to patch ld to make it easy, but all it does is back up the original and then copy the version from Xcode into the iPhone SDK’s location.

I wanted to make the script run automatically at the end of Step 2 but I could not figure out how to insert the script into the installer. If you know how, please let me know and I will improve iPhone313PPCInstaller.mpkg.

1. Open Terminal
2. Change the permissions to make the script executable (this is not preserved by the ZIP file)
   1. Type chmod +x ; note the space at the end
   2. Drag iPhone313PPCldPatch.sh into the terminal window
   3. Press the return key to set the permissions
3. Execute the script with admin privileges
   1. Type sudo ; note the space at the end
   2. Drag iPhone313PPCldPatch.sh into the terminal window
   3. Press the return key to run the script
4. The terminal output should look like the code snippet above
5. Restart your computer

If you want to manually verify it worked, you can use the lipo command again:

ichigodaifuku:~ me$ lipo -archs /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ld.backup.intel
i386
ichigodaifuku:~ me$ lipo -archs /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ld
i386 ppc7400
ichigodaifuku:~ me$ 

5. Run an App in the Simulator

Step 2	Step 3	Step 4	Step 5

We can’t deploy to device yet as there is more work to do, but you should make a sample app and make sure it launches in the simulator.

1. Open Xcode and select File→New Project
2. Choose any iPhone project you like but I chose “Tab Bar Application”
3. There is a toolbar item labeled “Overview” where you can change the deployment target from Device to Simulator
4. Now open one of the XIBs in Interface Builder to make sure that is working. Change some text so you know that the app runs properly when changed
5. Click Build and Run to compile the app, launch the Simulator app, and launch your new app

6. (Coming Soon) Run an App on Device

In the next episode, we will go through the steps needed to get an app running on the device. Remember, this is before Xcode could manage signing for you, so you will need to do it the old-fashioned way

As Cocoa developers, we were always taught that the NS in NSString, NSDictionary, NSArray, etc., stands for NeXTSTEP. So I thought, “What is it like to build an application for NeXTSTEP?” So I decided to try it! I got an OpenStep 4.2 Virtual Machine up and running, installed Project Builder (the precursor to Xcode) and got to work. MathEdit is the result.

Lessons Learned

The Good

OpenStep’s Foundation and AppKit frameworks are remarkable in that they are extremely complete even way back in 1996 (remember Mac OS X 10.0 Cheetah was released in 2001). If you ignore NIBs, then the code from OpenStep just works in OS X even to this day. Yes, there are many deprecation warnings, but all of the APIs work without issue. And yes, it means NSApplication, NSTableView, NSWindow, NSButton, NSMenu, the responder chain, etc all work exactly the same as they do now.

The Bad

However, there is a lot of core functionality missing. Networking for example. NSData will download things for you when you give it an internet path, but this has all the pitfalls of modern NSData. It’s single-threaded, blocking, has no progress, etc. If you want anything more than that you need to drop down to BSD Sockets. AppKit is missing basics like NSToolbar and NSDocument. Foundation is missing basics like NSError and NSURL, which kind of explains why there are all those duplicate methods with NSURL and NSString and with NSError and without NSError.

The Ugly

Lastly, there is the really hard stuff. Objective-C before “2.0” as Apple called it is pretty painful. That said, Objective-C 2.0 did not come to Mac OS X until 10.7, so that’s pretty late in OS X history. But still, we are talking about the most basic features missing:

• Automatic Reference Counting
• Fucking Block Syntax
• Property Syntax
• Dot Syntax
• Grand Central Dispatch
• Collection Literals

The other major pain point is Nibs. While OpenStep Nibs do work in early versions of OS X, Apple had a bad habit of changing the Nib format, XIB format, and then just refusing to load older Nibs for security reasons over the years. So the only way to make an app that is compatible across history is to not use Nibs… and unlike on iOS, AppKit really does not like this. I spent a lot of time getting memory management to work properly in early versions of OS X that just ABSOLUTELY ASSUMED you were using Nibs. I did get it to work, but this was like days and days and days of research. Also, I had to learn the secret trick to set the Application Menu which did not exist in OpenStep.

Features

MathEdit is basically like Math Notes from Apple. It’s a normal text editor like TextEdit, but if you type in a mathematical formula in the text, it automatically parses it and solves it for you. It makes extensive use of NSDecimalNumber and NSTextAttachment to do this. NSTextAttachment in particular is the star of the show. It still always shocks me that this was missing from iOS until iOS 7 even though it was in Mac OS X and even OpenStep before that. It is such a powerful way to enhance your text documents.

Caveats

I honestly don’t use MathEdit all that often. It is on all my Macs including my vintage ones and I think it is a cool proof of concept. But I don’t think it’s much more than that. But if you want to try it out for yourself, grab a build for your favorite Mac and give it a try.

https://github.com/jeffreybergier/MathEdit