7 ms·
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. The
by sanskarix 11mo ago
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 11mo agoIs 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 11mo agoAs low level as it gets. For lower level one needs something like ESP32, Arduino, retro-coding platforms.
- shreddit 11mo agoOf course it is. You just have to reimplement UIKit in ASM, no big deal…
- pjmlp 11mo agoAnd 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 11mo agoIt 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 11mo agoThe point is what is possible within the constrains of public APIs.
- fingerlocks 11mo agoEverything I described is in a public header right inside your iOS SDK folder
- pjmlp 11mo agoI 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 11mo agoIs 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 11mo agoNot 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 11mo agoNo, you’ll have to check in with backboard etc before it will let you do anything useful
- fingerlocks 11mo agoYou 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 11mo agoThis is an excellent argument for not using assembly, actually
- bilekas 11mo agoThe 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.
- saagarjha 11mo agoLearning assembly is useful, yes. Learning assembly by reading an app written in assembly…not so much.
- flohofwoe 11mo agoIt'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 ;)
- saagarjha 11mo agoYou can just cast it to a function pointer of the right type and use it, the ABI is C-compatible
- nurettin 11mo agoAll 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 11mo agoAssembly is fine until it breaks too
- szundi 11mo ago[dead]
- SoKamil 11mo agoYou still have whole Objective-C runtime and CoreAnimation, UIKit abstraction under the hood.
- bloomca 11mo agoYou 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 11mo agoComplete bogus. This is programmers machismo that's completely detached from reality.
- scrumper 11mo agoI'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 11mo agoThis is the most HN comment I’ve seen in a while. The real abstraction here is coding with LLMs btw!!!