Dev:RocketBootstrap

RocketBootstrap is a library that solves a denied lookup error of IPC services on iOS 7 and above.

"One common way processes communicate with each other on iOS and OS X is through a messaging system called mach ports. Each port is a channel that can either receive or send messages. There is a central registration system for these ports called bootstrap, where ports can be registered and accessed by a service name assigned to them. Recent versions of iOS restrict which names a process can access—MobileMail, MobileSafari and App Store apps are only allowed to access a very specific set of services that come with iOS. RocketBootstrap adds a secondary lookup service that doesn't restrict which processes can access which services."

How to use this library
Headers are available from RocketBootstrap's GitHub project and the library can be found at  on a device where RocketBootstrap is installed. If using Theos, place the headers in, the library in.

Makefile
Add to your Makefile:


 * to the  variable.
 * to the  variable.

Packaging
Add to your package's control file:


 * to the  field.

LightMessaging example
See LightMessaging.

CPDistributedMessagingCenter Example
Make sure you have the CPDistributedMessagingCenter interface declared.

CFMessagePort Example
(Pilfered from the NSHipster article on IPC)

Usage notes
If you want to run a server inside a daemon, then you still need a simple SpringBoard tweak, that just has to call  with the service name. Then you can run a server with the same name inside your daemon.

You shouldn't be registering Mach services in sandboxed apps; RocketBootstrap allows exposing services to sandboxed apps, but can't allow exposing services from sandboxed apps without exposing a very large security flaw.

Assuming there aren't any security problems, actually calling a service that's running inside of an app from SpringBoard (which is usually what people want to do) is problematic. Backgrounding apps causes them to enter a frozen "SIGSTOP" state, which means any calls to the service running inside of the app will block indefinitely.

Even if that is suppressed, it could happen that the SpringBoard part attempts to call the service running in the app at the same time as the app is trying to call any of the usual SpringBoard services. When that happens, they deadlock. This might happen infrequently, but it's a really bad failure case in that the system just hangs. Real users will encounter it, if it's present.

You can call from a background thread (not good, it could stay alive for a long time), or use timeouts (not good, now you have to tune it and you get UI hitches) or use asynchronous code (not bad, but it's more work than you may be willing to go through).