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.
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.
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.
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.
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.
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.
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.
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().")
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.
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 ;)
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.
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.
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.”
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)
<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 100€
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.
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.
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).
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.
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.
Looking at unistd.h, it seems marked as
and syscall numbers seem wrapped by in *<sys/syscall.h>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.
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.
For lower level one needs something like ESP32, Arduino, retro-coding platforms.
Would I use it for production iOS app, no, I don't hate myself that much.
And tbh I'm kinda surprised how little assembly code it is, less than most UI framework hello-worlds in high level languages ;)
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.
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)
https://stackoverflow.com/a/10290255/8427
Honestly wild if you need to upkeep the license just to have it in store once it is published.
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.
https://gist.github.com/anta40/60f62c803a091ad0415d60f8cac55...