What will be the result of the
libHandle = dlopen("/System/Library/SystemConfiguration/WiFiManager.bundle/WiFiManager", RTLD_LAZY);
I'm using this for getting wifi info on ipod os 3.1.2., because when I NSLog(#"Result %#",libhandle); I'm getting null what should be the answer,
thanks
According to this discussion, doing the above will return NULL on the iPhone Simulator, because it lacks the required bundle. If you are still running into issues with this on the device, it might be that Apple has changed the internal file structure for that system item. This is one of the reasons why it is bad to rely in private APIs.
For more on WiFi snooping, you might refer to the source code for this project, because they might have resolved these issues. However, once again I'd like to remind you that you will not be able to submit an application to the App Store that uses this, because of the private API calls. Apple is now scanning all submitted applications for these calls and instantly rejecting them.
Related
I agree that this question is duplicate. Please bear with me. I was also among you all to believe that is not possible to programatically turn on/off bluetooth.
But using GKPeerPickerController if bluetooth is not on user will be prompted to turn it on. Fair enough to turn on the bluetooth.
I was betting with my belief that we can not turn off the bluetooth programatically as there is no way. But this application does that so I didn't had choice to refuse.
I just want to confirm whether it is possible or not and if yes how to turn off the bluetooth using GKPeerPickerController or any other public api way ?
I know this isn't the answer you want, but no, you can't turn off bluetooth programmatically with Apple-approved APIs.
There have been a number of apps approved on the App Store this year that have done this.
But, they keep getting removed by Apple shortly after release, once they (Apple) realize what's going on. They're certainly using private APIs.
Either developers are foolish enough to think that they won't be noticed, or they are simply hoping to pull in a couple weeks of revenue before Apple pulls the app, which could be enough to pay back their cost, with some profit.
The issue is that there's a number of ways to check whether an app is using private APIs. If developers are using objective-C frameworks in the normal way, that's an easy check. In fact, Xcode does some of this automatically when you use it to upload app binaries to iTunes Connect. But, it's not a complete check. Once at Apple, the reviewers perform another check, which I've been able to deduce is more sophisticated than what Xcode does.
However, that check is still not perfect, and I'm of the opinion that it's not necessarily a matter of a lazy reviewer just forgetting to perform the check. Objective-C gives you some techniques for obfuscating method calls. Depending on how you use these techniques, you might get past the reviewers . In my experience, I have every reason (wink, wink) to believe that Apple is not running every app on a fully instrumented version of iOS, which could log all function calls, and defeat even the best attempt to hide private API usage via obfuscation techniques.
So, I can pretty much guarantee you that this explains the apps you've found on the App Store that turn off Bluetooth. Public GameKit APIs let you turn Bluetooth on, but not off.
Disclaimer: I've never worked for Apple, and no Apple insiders gave me information. But, I have gotten private APIs through the review process.
Please try below code and I think it will also work for you.
Class BluetoothManagerClass = objc_getClass( "BluetoothManager" );
BluetoothManager *btCont; = [BluetoothManagerClass sharedInstance];
[btCont setPowered:NO];
You need to add BluetoothManager class/framework in your project.
Thanks
I've been looking for a way to compare timestamps between applications on the same phone in real time, and NSDistributedNotificationCenter sounded like an ideal solution since i may not know the names of the apps listening for it, but it sounds like its not available in iOS.
Is there an equivalent way of notifying multiple apps of a time-sensitive event without knowing their name?
Coding for iOS 5+ and assuming the apps in question will register for the notification.
Look at CPDistributedMessagingCenter in /System/Library/PrivateFrameworks/AppSupport.framework. However, it's a private framework (may change with OS releases, and not allowed in AppStore).
Documentation here: http://iphonedevwiki.net/index.php/CPDistributedMessagingCenter
Example codes of mine here:
https://github.com/H2CO3/PwnTube
https://github.com/H2CO3/Cereal
I'm pretty sure you can use Mach ports. They are a bit low level but work well.
i found a way to use CFNotificationCenterGetDistributedCenter() on iOS. It is exists on device, but not exports in iOS SDK
void *libHandle = dlopen("/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation", RTLD_LAZY);
CFNotificationCenterRef (*CFNotificationCenterGetDistributedCenter)() = (CFNotificationCenterRef (*)())dlsym(libHandle, "CFNotificationCenterGetDistributedCenter");
if(CFNotificationCenterGetDistributedCenter) {
CFNotificationCenterAddObserver(CFNotificationCenterGetDistributedCenter(), NULL, &NotificationUpdateApp, CFSTR("TestApp"), NULL, CFNotificationSuspensionBehaviorCoalesce);
}
dlclose(libHandle);
Not really. The closest you can do to what you’re asking, on a non-jailbroken device, is have your server talk to each other app’s server and have that server send a push notification to the app in question. Without NSDistributedNotificationCenter (which is, as you surmise, not available on iOS), you don’t really have any other option.
This question is a little bit old, but I'll post my answer just for information purposes.
NSDistributedNotificationCenter is not available for iOS yet, and unless your are developing an app that you don'd pretend to release on AppStore, you can't use AppSupport.framework because it's private.
iOS8 released App Extensions, that give us the ability to communicate with other apps. I don't know what you are trying to do exactly but I believe that if you are just trying to compare some timestamps from some other apps, it should resolve your problem.
Link to AppExtensions documentation:
https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/
Hope it helps somebody.
NSDistributedNotificationCenter exists on iOS, but the headers aren't made available to developers.
Create a header file in your project with the following to make the class available:
#interface NSDistributedNotificationCenter : NSNotificationCenter
+ (NSDistributedNotificationCenter *)defaultCenter;
// Returns the default distributed notification center - cover for [NSDistributedNotificationCenter notificationCenterForType:NSLocalNotificationCenterType]
- (void)postNotificationName:(NSNotificationName)name object:(nullable NSString *)object userInfo:(nullable NSDictionary *)userInfo deliverImmediately:(BOOL)deliverImmediately;
#end
This is very useful when trying to get information from an App to its UITest runner, but you should obviously NOT attempt to put this in the AppStore.
I've created a project XCTestBackChannel to show this off.
One of my apps is in the appstore and I got a call from one of our clients saying a specific feature in the application is consitently causing the app to crash. However, I don't see any logs in iTunes Connect rightnow. Is there a delay between the app crashing and the log being submitted? If so, how long does it usually take?
Thanks,
Teja.
You'd be better asking them to send you crash reports directly. If they sync their handset using iTunes there will be a copy on their PC/Mac.
Unfortunately it seems that people are syncing their phones less and less often. (Which means they never make it into iTC.) Also, not all of them make it into iTC. Apple aggregate them but there also appears to be some level of filtering. What they do is not documented.
This blog explains what I ended up doing with my apps.
You should use a service like Crittercism - They give you real-time crash reports. You could also use something open-source like PLCrashReporter if you want to implement the server yourself.
The delay really depends on how long it takes before the user syncs their device with iTunes. I believe after that it's pretty quick.
Also it's worth noting that iTunes Connect needs a few crash reports before it displays them.
How exactly does apple approve apps? Is the actual source code viewed?
While none of us have access to the internal review process (which appears to be continuously changing), there are a few things that can be said based on the responses that people have received.
First, Apple has no access to your source code, so they do not review that. You submit a binary as part of an application bundle, along with your other application resources.
They do, however, appear to scan your application's binary for certain symbols that indicate the use of private APIs. A number of applications started crashing after iPhone OS updates because they used these private APIs, so Apple has been cracking down on this.
There are plenty of applications on the store that have memory leaks or other performance issues. I know that I've submitted versions of my applications that had subtle leaks (since fixed) and had no problems with review. Therefore, it does not appear that they do any sort of performance testing or profiling.
The only place where a memory leak causes a problem doing review is when that memory leak gets so bad that the application crashes when the reviewer is testing it. If your application crashes at any point during the review process, it will be rejected.
Beyond that, they have a checklist of user interface elements that they check for proper usage of (no persistent selections on table view rows, etc.). If your application deviates significantly from the Human Interface Guidelines when using these standard UI elements, you may get rejected.
Apple is very careful about copyright, particularly with their own images and artwork, so you may run into trouble if you use copyrighted material improperly.
Most of the rejection reasons you will face are preventable by making your application stable and by following platform guidelines, but some are not. Certain classes of applications have been rejected due to their intended use, and again the classes of applications that are allowed on the store change on a regular basis. This can add frustration and uncertainty when dealing with the App Store, but the vast majority of application types will never run into problems (as can be seen in the diversity of applications currently available).
try to use otool -L binary yourself and you can see immediately if a private API framework got used...
No, they only have access to the binary code that you send them.
They can run this through profilers checking for memory leaks and the like.
They do not have access to your source; it is not part of what you send to them. They test the binary you send them for leaks and such. I think they also check what data your app sends out to make sure it isn't doing anything egregiously bad (sending passwords or the like).
Apple does not care about leaks and profiling information for your App. The Operating system is able to kill your app if that gets out of hand. What they actually do is manually run your App and check if it follows some of Apples guidelines. In an automated process they extract symbols, selectors and strings from your binary and check those for usage of private APIs.
You might want to try nm -u on your (simulator) binary.
They only receive your binray file of ipa only. They can get some of your resource file while extract ipa. They can able to find what all urls you used in web service or url request. Nothing else other than this.
Some of our application is already in AppStore...
But suddenly one thing comes into my mind, that I want to clear before submitting my next application.
The thing is : As a programmer's point of view, should we require to handle if iPhone Device is jailbreaked ? If yes, then how we can tackle with this ?
Thanks in advance....
On a general note, jail-breaking the device is an issue between the user, Apple and potentially the carrier. You are not a side in this relationship, and the user has no contractual obligations to you with regards to their device.
You could choose to attempt detecting jail-broken devices in an attempt to prevent piracy of your app. However:
If the device is jail-broken, there's nothing you can do to reliably verify it's not jail-broken, since none of the OS APIs (including networking) is guaranteed to function as you expect. Your code could be running in a non-jail-broken simulation on top of jail-broken device.
Of course, you could check by attempting to do one of the things you currently know Apple actively prevents apps from doing. However, there's no guarantee that Apple is not going to allow that particular action in future. And, there's the chance that your app might get rejected because you are attempting to do something prohibited by Apple.
There is no official criteria from Apple on what constitutes a jail-broken device and what does not. And even if there was, you are not guaranteed to be notified in a timely manner (or at all) by Apple if they decide to change any such criteria. But even assuming you do get notified somehow, you can't update your app quick enough to avoid falsely detected jail-broken devices, thus potentially denying access to your app to legitimate users.
If you would like to cut off a large group of users, then sure, go ahead and require it.
Unless your application specifically requires it, there should be no reason to force users to have a jailbroken iPhone or a non-jailbroken iPhone.
If you program is legitimate (no private API calls etc), then you should not concern yourself with JB. You don't need to handle anything differently if the users phone has been JB'd. If it has, and your software doesn't run (say memory issues because they are using backgrounder to run 2 other things) then that's their problem not yours. Make your code well behaved, not leak memory, dump cache's etc with memory warnings, and you should be fine.
As you asked for the "programmer's point of view", I'd say: make sure your app runs on as many devices as possible.
Meaning: as long as you app is safe to run on an iPhone whether it's JB or not, I wouldn't care.
One thing I have found, at least early on (not seen it for a while) is that most reports I got of strange behaviour with my app (vConqr) turned out to be from people with jailbroken phones.
That's not to say I think that's good reason to block them. But if you do any sort of custom crash reporting, or other diagnostics it could be useful to log the fact to save time on troubleshooting.
Do a search on the Internet. You'll find several articles that shows some ways you can detect a pirated app. I make no claim on their effectiveness, but I do use some of these in my own apps. These techniques do not try to detect if a phone is jailbroken; they focus on detecting if your app has been tampered with.