Is it possible to make a system call, such as executing ls -la, and use the result in your app?
Usually when someone says system call they mean calling into the kernel through one of the defined entry points. While its technically possible on iPhone, you are always better of going through the libSystem shims because the call interface is probably not stable (it isn't on Mac OS X for instance). I doubt Apple would like it if you did that, but I suspect no one as really thought about it much and they are unlikely to notice.
I don't think that is what you mean though. I think you want to use ISO/IEC 9899:1990 (C90) C libraray function "system". The answer to that is no, you can't.
Sadly syscall.h under iOS is a private api. While you can use it in private applications Apple will not allow you to use the syscall() API for App Store submissions unfortunately.
Related
Does Apple allow the usage of sysctl.h within iOS applications?
PS: App Scanner, a third party tool that checks code for possible private-API usage seems to think it's okay.
Note:
There is one more question like this : How can I know if I'm using private frameworks?
With the usual disclaimer that nobody can tell you what a reviewer will do, I can say for sure that there are apps in the store that use sysctl functions.
(Minor point: Simply including a header isn't a problem since symbols there shouldn't be visible in your app unless they're used...it's the things you use that might get flagged rather than what's included.)
So I know it's possible on a jailbroken iOS device to inject a dylib into a running process and interpose/hook system functions. I'm wondering if it's possible on a non-jailbroken device to interpose system functions at either link or run time, assuming I'm the one building the app? Maybe the equivalent on linux of using dlfcn and LD_PRELOAD?
An example: I want to take an app I've built that uses various Cocoa/Core Foundation abstractions for filesystem access and wrap the underlying open/read/write/close calls. I know about swizzling in Objective-C, but I'm looking for something at the libc level so I capture everything. This is for something test/debug related so it doesn't need to be App Store friendly. Thanks!
No, it's not possible (to my knowledge) on non-jailbroken iOS device. All traditional forms of dynamic loading (interposing, dlopen/dlsym, etc.) have been removed.
Since you mention that your needs are related to test/debug, you might want to try to make use of DTrace if your problem exists on simulator. You can use DTrace on simulator, but not on real iOS device.
Is it possible to manage the memory of a process alien to itself in iOS?
By this I mean to be able to read and write bytes on iOS applications, something like ReadProcessMemory and WriteProcessMemory functions of Windows.
I know I have to program in Objective-C, but I do not know if these functions exist in it, or if iOS has them in its libraries. Or something similar to them.
Any hints?
This will absolutely get your rejected from the app store, so there is no reason for them to exist in objective-c. If you don't need to submit the app to the app store, you will need to look into unix tools and a possible jail breaking requirement.
Are any squeak's etoys like apps available for download to the ipad?
Squeak running on iPad.
n.b. The Smalltalk mailing lists, accessible and searchable via http://forum.world.st/, are the first place to look for this type of question (the installation instructions below were the second hit for "iphone" there.
Bert ported eToys to the iPad, but as you can read here, it seems more like a proof of concept than something you would use every day.
IIRC, even though Apple changed course to allow other languages on the iPhone/iPad, you still can't download code, which means you will not find Bert's port in the app store (I think downloading projects, which are Smalltalk, is prohibited). If you want to install eToys or any other Squeak variant onto your personal iPhone, you can start here to find out how.
While I understand that in order for an iPhone application to be accepted on the App Store, one requirement is that only documented libraries are to be used.
If this is the case, how are certain applications such as "Night Camera" and "Camera Plus" using a camera control that seems to be something other than the one contained within UIImagePickerController?
I have heard of certain cases where a developer has been given "special" access to certain headers that allow for features that would otherwise be impossible if constrained to only using documented libraries. However, given how opaque the application selection process is for the App Store, I would prefer to stick to what is recommended rather than take my chances.
Anyone care to shed some more light on this?
Have you seen this dicussion?
http://blog.airsource.co.uk/index.php/2008/11/11/views-of-uiimagepickercontroller/
and this sample code for a custom picker?
http://www.codza.com/custom-uiimagepickercontroller-camera-view
hope it helps.
You might want to check out a classdump of apple's private framework headers. Run this perl script:
http://arstechnica.com/apple/news/2008/11/dumping-the-iphone-2-2-frameworks.ars
and navigate to the PhotoLibrary directory under PrivateFrameworks. Some of the classes in here look pretty promising for direct camera access.
Using the undocumented API could hurt your chances of passing through the app store, but it's all very subjective - If your product is good, apple will probably let it slide through. I'd recommend making friends with a developer evangelist at Apple.
The UIImagePickerController is a UIViewController subclass that manages a view hierarchy. You are free to play around with the view hierarchy, as those apps are, but it is risky considering that Apple does not document it and could change it on any OS update.
I have not heard of anyone being given special access to libraries, but I have read that there is a minor distinction between undocumented classes and methods and private frameworks. Undocumented classes are a gray area, but private frameworks are definitely not allowed.
The simple explanation is that apps in the store are not supposed to use unsupported APIs, but this is not checked consistently. The apps you mentioned are either using unsupported functions/classes/methods or else are playing with the view hierarchy-- which is itself undocumented even though it can be done with standard APIs.
You could do what they do, and take your chances with it. Just be aware of the risks. Your app might (a) be rejected from the store, (b) be accepted but later booted (this has happened for unsupported API use), (c) be accepted and not booted but break the next time Apple has a new iPhone software update (since unsupported APIs or view hierarchies can change without warning). Or you could get lucky and have none of this happen.