Honestly wild if you need to upkeep the license just to have it in store once it is published.
For lower level one needs something like ESP32, Arduino, retro-coding platforms.
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.
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.
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().")
#ifdef __APPLE_API_PRIVATE
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.
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.
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 ;)
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.
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)
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.
We’ll just leave things as they are.
I’ll forfeit the game.
The field is yours.
Have a great day!
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://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)
starmole•3mo ago
saagarjha•3mo ago
anta40•3mo ago
https://gist.github.com/anta40/60f62c803a091ad0415d60f8cac55...
saagarjha•3mo ago
zffr•3mo ago