Hacking with private APIs on iPad | Hacker News Reader

Hacking with private APIs on iPad

rambo.codes

73 pointsingve21 comments

JSBox source code: https://github.com/cyanzhong/xteko

> JSBox is not only a full-fledged environment for standard JavaScript, but also provides many utilities: safe environment to run JavaScript natively ... editor to write JavaScript, multiple themes, auto completions and snippets... VSCode extension ... APIs to interact with iOS ... Almost all the cool tech in iOS: Today Widget, Action Extension, 3D Touch, Home Screen

Discovery is non-existent on the App Store. Other than blog posts, is there a good way to find new scripting/dev environments as they are released for iOS?

https://scriptable.app is another JS runtime.

https://codea.io is a Lua runtime.

Pythonista is as it sounds.

Pythonista is fantastic, especially if you get StaSH — a shell and basic userland written in PyPy to replicate as many POSIX tools as possible.

I second this. You can easily invoke Cocoa classes and swizzle methods with it. My eldest figured out how to snapshot a WebView inside Pythonista that way.

You need iSH, a full Alpine Linux environment, emulated on iOS. It’s still in beta, but surprisingly functional.

https://github.com/tbodt/ish

I know this is a silly comment but: 12” iPad Pro made my brain skip a frame.

12.9” rounds up to 13”. I carry both a 12.9” iPad Pro and a 13” MBP, and they are practically the same size, the iPad is slightly bigger on the small dimension and the MBP noticeably wider on the large one, due to the different aspect ratios. Picked up the iPad to use with Duet, and have been pleased with the combo, nice to have two full screens to work with while coding.

Ok, nit picked. ;-)

All 13" MacBooks are actually 13.3", 15" are 15.4”.

Which round down to 13" and 15" respectively, which is my point.

12.9" is awkward, 12" more wrong than right, I'd call it the 13" iPad if I had to pick one, but it's branded as 12.9".

I use Continuous [1] for C# and F# coding on my iPad Pro. It implements a lot of Native iOS libs like UIKit, SceneKit, SpriteKit, Foundation, and CoreImage, but I am not sure if it can do what the article here does with Pythonista, which I also use on my iPad Pro. It has code completion and debugging, and code changes update very quickly for interactive development.

[1] http://continuous.codes/

I’m pretty sure Frank (the author) had some samples of how to fish out private frameworks. Apple does frown on that a bit, but since they’re usually exposed to the sandbox as read-only, you should be able to do the same.

Thanks, I'll have to check that out. I am not beholden to any OS or platform. I have Windows 7 (at work), Windows 8.1 and 10 (at home), Linux, and an iMac and iPad, and I am amazed at how great the developing and coding experience can be on my 2015 iPad Pro. My other notebooks are all four-plus years old, but I have heard the latest iPad Pro is even faster and more capable for serious work. The Smalltalk/Pharo environment is pretty amazing, but coding F# on the iPad with Continuous is close to it.

Swift Playgrounds example doesn't work on 12.1:

assert(Bundle(path: "/System/Library/PrivateFrameworks/AvatarUI.framework")!.load())

Error: Unexpectedly found nil while unwrapping an Optional value.

This framework doesn’t exist on my iPad. Either Apple has removed it from non-Face ID capable iPads, or dropped it altogether.

Yes, the framework isn't installed on devices that don't have the Face ID camera — because there's no use making Memoji (what AvatarUI.framework is for) without it.

Works for me on 12.1.1 on iPad Pro with FaceID.

That means your device doesn't have the Face ID camera and therefore doesn't include the AvatarUI framework, responsible for making Memoji.

This is the number one thing that turned me off of the Apple development ecosystem. Their absolute insistence on providing headers-only distributions of their libraries. It makes absolutely no sense. They're not protecting some closely guarded trade secret here, it's just a bunch of Objective-C UI code. And then the moment you need to change the color of something... or change the most trivial implementation detail in a base class, you're left completely starting from scratch.

They're undocumented APIs, not private APIs, they will eventually be documented anyway.

No, these are very much private APIs.

What's the practical difference on a proprietary platform where you can't just look at the source code to find out what it does?

Undocumented APIs are exactly that: you are free to call them, but there isn't any information on how to do so (for iOS, this is often POSIX or Mach functions). Private API is intended to be used by Apple exclusively, and is indicated as such by not being in /System/Library/PrivateFrameworks, or included in a usual framework but not intended to be called–either by prefixing the method name with an underscore or not being included in the class's documentation. Private API is occasionally opened up to third-party developers, but this is usually quite rare.

Reply on news.ycombinator.com