[HN Gopher] Hello-World iOS App in Assembly
___________________________________________________________________
Hello-World iOS App in Assembly
Author : pabs3
Score : 170 points
Date : 2025-10-30 02:37 UTC (20 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| starmole wrote:
| Super cool! Would love to see the build/deploy steps needed.
| saagarjha wrote:
| xcrun -sdk iphoneos clang yellow.asm, pack it into an IPA and
| sign it
| anta40 wrote:
| Hmm doesn't work. Here's the error log (I'm on Mac M2):
|
| https://gist.github.com/anta40/60f62c803a091ad0415d60f8cac55.
| ..
| saagarjha wrote:
| Maybe throw in a -framework CoreFoundation
| zffr wrote:
| I just tested this on my computer. 1. Make a
| new Xcode iOS project and delete all files except for
| Info.plist 2. Remove all keys from Info.plist 3. In
| the build settings search for "storyboard" and remove all keys
| 4. Add yellow.asm to project 5. Link UIKit, and
| Foundation
|
| After all that you can build and run on a simulator
| JimDabell wrote:
| There is also an iOS app implemented in C here:
|
| https://stackoverflow.com/a/10290255/8427
| baumschubser wrote:
| snibbetracker is an example of a C/SDL iOS app. <1MB from the
| app store which is really wild.
| https://apps.apple.com/de/app/snibbetracker/id1065797528
| c-fe wrote:
| <1MB is also relatively easy to reach with swiftui apps. I
| had two fully working ones in the app store below 1MB. They
| are removed now since I didnt pay the yearly 100EUR
| bloomca wrote:
| Do you need to pay the license to keep your apps in store?
| Or did they deprecate some APIs and therefore removed your
| apps?
|
| Honestly wild if you need to upkeep the license just to
| have it in store once it is published.
| BrianHenryIE wrote:
| Yes. I have a bike helmet with integrated cameras. The
| company (Cyclevision) that made it is gone. So no Apple
| account. So no app for my helmet anymore.
| klardotsh wrote:
| This is yet another example of why open bootloaders to
| allow alternative firmwares for all gadgets must become
| legally required. Stuff turning into eWaste (or at least
| losing what some folks would likely call major
| functionality) because the creators went out of business
| and the gadget was locked down is a disaster for both the
| planet and for the concept that you actually own the
| stuff you buy.
| anta40 wrote:
| Even better if build steps are provided
| azhenley wrote:
| I'm guessing even this still requires that I use XCode.
| abnercoimbre wrote:
| Is that true? What about the command-line version?
| klausa wrote:
| The Command Line Tools doesn't include the iOS SDK; or a
| simulator; or any of the other tools required to get it
| deployed to actual device.
| dadoum wrote:
| It probably doesn't, as you practically never need Xcode for
| simple apps. From my experience, currently, you need Xcode to
| compile storyboards (NIB/XIB files) and bundle Assets.car
| (macOS BOM files); and compile Xcode projects, btw. I may be
| missing another important feature used in a lot of apps but
| otherwise for the most part you can build an iOS app without
| Xcode (or even macOS).
| pjmlp wrote:
| The command line tools are still XCode, in a way.
| sanskarix wrote:
| This kind of thing is how you actually learn what's under the
| hood. Everyone's building with React Native and Flutter, which is
| fine until something breaks. Then you're stuck Googling black
| magic. Starting from assembly teaches you the real cost of
| abstraction.
| internetter wrote:
| Is this really low level though? Because its hooking UIKit
| which is very high level relative to ASM. I'd be really curious
| to see an app draw on iOS without UIKit. I don't know if thats
| possible.
| pjmlp wrote:
| As low level as it gets.
|
| For lower level one needs something like ESP32, Arduino,
| retro-coding platforms.
| shreddit wrote:
| Of course it is. You just have to reimplement UIKit in ASM,
| no big deal...
| pjmlp wrote:
| And even that won't do it, because within the constraints
| of iOS, eventually that framebuffer with software rendering
| has to be displayed on the screen via an OS API, which is
| UI Kit.
| fingerlocks wrote:
| It should be possible.
|
| If you enable the JIT entitlement for personal
| development, then bundle a mach-o into an entitled app.
| Or compile it directly on the app and mprotect-x to
| execute it. Is there something else you can't do that I'm
| not considering? I might give this a try.
| pjmlp wrote:
| The point is what is possible within the constrains of
| public APIs.
| fingerlocks wrote:
| Everything I described is in a public header right inside
| your iOS SDK folder
| pjmlp wrote:
| I doubt you can render an UI in pure Assembly and show it
| on the screen without going through UI Kit in a non-
| rooted device, given that even the device drivers
| extension points is quite limited.
|
| Which was the whole discussion point that started the
| thread, how to make a iOS app with zero references to UI
| Kit.
|
| This isn't an 8 and 16 bit home computers, or games
| console, with an address for the framebuffer.
| Someone wrote:
| Is _syscall_ a public API on iOS? In the end, you have to
| call that to get anything on the screen?
|
| Looking at _unistd.h_ , it seems marked as
| __OS_AVAILABILITY_MSG(ios,deprecated=10.0,"syscall(2) is
| unsupported; " "please switch to a supported
| interface. For SYS_kdebug_trace use kdebug_signpost().")
|
| and syscall numbers seem wrapped by
| #ifdef __APPLE_API_PRIVATE
|
| in *<sys/syscall.h>
| pjmlp wrote:
| Not at all, it is a Linux thing to keep applications
| doing syscalls, like back in MS-DOS interrupt days.
|
| All other modern OSes give zero guarantees about
| syscalls.
|
| Indeed, you have to call UI Kit, that is the public API
| for userspace applications.
|
| Even if via OpenGL ES or Metal, you need a drawing
| context and a Window to render it.
| saagarjha wrote:
| No, you'll have to check in with backboard etc before it will
| let you do anything useful
| fingerlocks wrote:
| You can write directly to the frame buffer, like a video
| game. You still need the UIKit import to publish, because it
| has to be bundled into a .ipa which requires an AppDelegate,
| a UIBundle, among other things.
|
| If you want to "technically" avoid UIKit, you can drop one
| step lower. UIKit is implemented on CoreAnimation. A bare
| UIView is nearly a pass through wrapper around CALayer. It
| wouldn't be hard to build your own custom UI on CALayers. The
| old CA tutorials for implementing a ScrollView from the
| ground up are still floating around out there.
| saagarjha wrote:
| This is an excellent argument for not using assembly, actually
| bilekas wrote:
| The argument is that learning assembly is useful, it gives
| some insights into what happens under the hood. That seems
| like a no brainer to me.
|
| Would I use it for production iOS app, no, I don't hate
| myself that much.
| flohofwoe wrote:
| It's still very educational. It shows how ObjC method calls
| work under the hood, because even calling objc_msgSend() from
| plain C involves a certain amount of non-obvious magic
| (because of the variable argument list and return types).
|
| And tbh I'm kinda surprised how little assembly code it is,
| less than most UI framework hello-worlds in high level
| languages ;)
| nurettin wrote:
| All this teaches is how to put parameters on stack, pass them
| to functions and use the results. It is pretty much a
| transliteration of what you would do in C.
| JojoFatsani wrote:
| Assembly is fine until it breaks too
| SoKamil wrote:
| You still have whole Objective-C runtime and CoreAnimation,
| UIKit abstraction under the hood.
| bloomca wrote:
| You have a very long way between assembly and RN/Flutter. I do
| agree that it helps to know these things, but you need to learn
| a lot more before it becomes more generally applicable.
| wiseowise wrote:
| Complete bogus. This is programmers machismo that's completely
| detached from reality.
| scrumper wrote:
| I'm not sure this is entirely fair though I think you're
| mostly right. The comment you're replying to is right in
| terms of the value of understanding one or more levels of
| abstraction below the one you're working in. Conversely
| you're right in that learning assembler isn't going to do
| much to help you debug a failing Flutter app. It's just
| attacking the abstraction stack in detail from the opposite
| end - equally myopic.
|
| But none the less valuable because of the additional
| perspective it brings. That's the real point of it, another
| lens through which to view and understand the mechanics of
| the application.
| shay_ker wrote:
| This is the most HN comment I've seen in a while. The real
| abstraction here is coding with LLMs btw!!!
| ChrisMarshallNY wrote:
| Very cool, if impractical (it's likely that you'd never get an
| ASM app through the App Store Approval process).
|
| ARM Assembly is a much more Byzantine creature, than the old 8-
| and 16-bit versions I used, way back in the Pleistocene.
|
| I'm always a fan of starting from the "bare metal," to learn, but
| these days, it's a long trip. When I was just a wee sprog, it was
| only a couple of steps away.
| Fokamul wrote:
| It's likely in future, you won't need app store approval
| process. I hope that EU will nuke Apple with some huge fines.
|
| And there will be corporate tax per each EU country, it's
| ridiculous corporates are raking huge money here and paying
| basically nothing on taxes, well only in Ireland and they're
| having party.
|
| Anyway, asm is great if you are using iOS emulator and need to
| do something and since you have root there, well :) (not apple
| meme simulator)
| jeroenhd wrote:
| You can already deploy apps on alternative stores inside of
| the EU. Apple has some bullshit fee but Epic has promised to
| cover that for AltStore.
| Ecco wrote:
| How would that impact the App Store approval? AFAIK they review
| binaries anyway...
| ChrisMarshallNY wrote:
| They do, but ASM doesn't have the guardrails that the
| compiled languages have, so it's almost certain that private
| APIs would get accessed.
| einsteinx2 wrote:
| What? That doesn't make any sense. The only guard rails
| normal Obj-C has against calling private APIs is that they
| aren't listed in the public headers, otherwise you can
| still easily call them. If you don't explicitly make calls
| to private APIs from ASM, the won't be called. I have no
| idea why you think "it's almost certain that private APIs
| would get accessed."
| zffr wrote:
| > so it's almost certain that private APIs would get
| accessed
|
| No it's not. Just like with ObjC or Swift, in ASM you have
| to be explicit about the APIs you want to call. I don't see
| how you would accidentally call a private API in ASM.
|
| IMO the bigger risk is attempting to call a method that
| does not actually exist. ObjC or Swift would protect you
| from that, but ASM would not and may just crash at runtime.
| ChrisMarshallNY wrote:
| Tell you guys what.
|
| We'll just leave things as they are.
|
| I'll forfeit the game.
|
| The field is yours.
|
| Have a great day!
| Ecco wrote:
| Feels like a disassembly of a boilerplate app, as opposed to
| handcrafted, minimal assembly code.
|
| For instance I'm pretty sure the autorelease pool is unnecessary
| as long as you don't use the autorelease mechanism of
| Objective-C, which you're most likely not going to do if you're
| writing assembly in the first place.
| avidphantasm wrote:
| Looks more sensible than having to use XCode and Apple's
| atrocious developer documentation.
| herodotus wrote:
| When I was in second or third year of computer science in 1971 or
| '72, we (of course) learned IBM 360 assembler, but we also had to
| design a simple binary adder using AND OR and XOR gates. All on
| paper - no need for any soldering or electronics, which I regret.
| I cannot remember how many bits of input - probably 4 but may
| have been 6. But I did do quite a bit of asm programming,
| including a routine for calculating square roots using Chebyschev
| polynomials and newtons algorithm.
| iMario wrote:
| Would love to see equivalent in C, not ObjectiveC... plain C.
| incanus77 wrote:
| That would be great if iOS supported a GUI in C.
| WillAdams wrote:
| For folks who are curious about this sort of thing and want an
| approachable starting point, I would recommend:
|
| https://www.goodreads.com/book/show/44882.Code
|
| It would be way cool to see an actual application which wanted
| this sort of speed optimization --- the last significant assembly
| language program I can recall using was WriteNow, which was
| ~100,000 lines of assembly and to this day is my favourite word-
| processor (well, the NeXT version --- the Mac, even v2.0 suffered
| in comparison for not having access to Display PostScript and
| Services).
|
| Really wish that there was a writeup of it at folklore.org ---
| unfortunately, it only gets a single mention:
|
| https://www.folklore.org/The_Grand_Unified_Model_The_Finder....
|
| (or that there was an equivalent site for the early history of
| NeXT)
| meisel wrote:
| The real optimization here is to move off UIKit and interact
| with the GPU more directly
___________________________________________________________________
(page generated 2025-10-30 23:01 UTC)