My iPhone app was rejected with the following note:
The following non-public APIs are included in your application:
Spi Symbols
__memset_chk
__memmove_chk"
These symbols appear in a small number of apparently cocos2d related object files:
Grid.o
Primitives.o
TextureAtlas.o
Curiously, this app had already been approved under the previous SDK, but under 3.2 it's being rejected, though that may have nothing to do with it.
I'm not at all sure how to resolve this and appreciate any help anyone can offer. Thanks.
If cocos2d is using non-public API, I would suggest you first check if there is a newer version available that fixes this issue.
If you are already using the latest version then you should file a bug report with the cocos2d project and hope for a quick fix.
Related
I have an application that uses HealthKit and Swift in it, everything compiles and runs fine when I test it from Xcode on a simulator or a device. I tested, debugged it, and submitted it to the iTunes store. When the application was approved I downloaded the new version from the store and it crashed right away. This was extremely puzzling as I have never had this issue before. I look at the diagnostic and usage logs on my phone and the crash report for the application says this:
Dyld Error Message:
Library not loaded: #rpath/libswiftCore.dylib
Reference from: /path/to/my/app
Reason: no suitable image found.
Did find: /path/to/my/app/Frameworks/libswiftCore.dylib: mmap() error 1 at address=0x100174000, size=0x0194000 segment=__TEXT in Segment::map()
Has anyone seen anything like this or know how to deal with it?
Thank you
EDIT:
The crashing issue magically fixed itself on the morning of October 4th, which tells me that this was an Apple issue. I have been emailing iTunes Connect Support, but they have not said one way or another what happened. I also opened a technical ticket without even a response back from Apple. This is pretty disappointing, not just for the fact that Apple is not being transparent about the issue, but also it makes me feel like I have no course of action later on down the road if this ever were to happen again.
Simply do the following two steps:
1) Delete the App from the device (or simulator)
2) Clean your workspace (CMD+SHIFT+K or via menu Product->Clean)
3) Build and run your app again.
Magically helps every time with all that startup / deploy stuff...
I also often get something like "application not found on device" or signing problems etc. Minutes before everything worked well.
This appears to possibly be a code signing issue on Apple's part, and the issue seems affect apps with embedded frameworks (including non-Swift apps). There are multiple accounts of developers being affected (myself included) who had only submitted an update, without changing any build settings. Some high profile apps appear to have been affected and tickets have been filed with Apple, but there has been no official response from them at this time.
EDIT: This has been confirmed.
Edit:
The app was rejected, after making this change, for the same reason, however, I am confident that the problem has to do with a missing architecture version in the libswiftCore.
I am going to post this as the provisional answer.
Xcode 6 Standard architectures exclude armv7s
Notice how the error says: Did find: /path/to/my/app/Frameworks/libswiftCore.dylib
So it did find the lib but it also says: Reason: no suitable image found.
After running lipo against the archived build it didn't contain armv7s in the swift library, or in the app binary. I manually added it per the link above and the binary now contains support for armv7s though the swift library still did not. My app is in expedited review so I should get feedback farily quick. I will follow up when that does happen.
I had the exact same problem with one of my app version updates (FunKeyBoard 1.1).
After doing some research, looks like it was an Apple side issue for many apps updated on October 3rd. Apple fixed the issue on October 4th by releasing an update, same version number, without needing any fix/re-upload from the app developer.
Obviously an Apple side issue, but I'm surprised Apple is very quiet about it. Many developers, including myself, got angry emails from users, and poor app reviews, as a result.
This error typically occurs when signing Swift apps with certificates that lack "OU" (Organizational Unit). All certificates created after the release of iOS 8 should have this. The simple solution is to create a new certificate to sign with.
For more details, see the official Apple comment here: https://developer.apple.com/library/ios/qa/qa1886/_index.html
It seems that my on the iTunes store is now downloading and opening as expected. From what I have been reading in the Apple Developer Forums, other apps are also working now too. I have not received any word from Apple on why this happened or what caused this. I opened up a technical support ticket with them and I also contacted iTunes Connect support and there is no
explanation or any information on this issue being resolved. This is pretty poor customer service on their part.
I had the same problem. I removed support for arm64 and added armv7s and now apple review team approve the app.
I have just uploaded an app and Application Loader has given me this warning. I went on to see what does this mean and found that I am using some third party APIs due to which it might get rejected. Can I know due to which library or which code is it saying like this?
Also, is my app really gonna get rejected for sure? I don't wanna wait for 10-12 days and then know that my app got rejected. How do I confirm this thing that it won't or would get rejected in a shorter time?? Please help.
Okay got the answer myself. The Flurry SDK which I was using was an older Version V2. When I updated to V3 and the problem is resolved. Anyways thanks. :)
p.s You can check if your Flurry is outdated by checking your header file. If it says, FlurryAPI.h it is V2 and if it says FlurryAnalytics its V3.
You must be using some undocumented method in your app.
Does anyone know if version 2.2 (the latest) of Apple's iOS 'Reachability' example code will run on iOS 3.0?
I want to support iOS 3.0, and Reachability.h and .m is the first non framework code I'm using in my app. In my own code I usually read the docs for all methods I use, and use respondsToSelector: to implement methods that won't run on 3.0.
When people use third party code, how do they confirm which iOS it supports without checking every method individually against the docs?
Alternatively, does anyone know how I can get my hands on the old version of the example code? (Reachability version 2.1 might help.)
I don't mean to snipe an answer from #Matt and #Martin, but I feel like this question deserves an answer for posterity. If they come back and post their comments as answers please feel free to accept them.
Anyway, my own answer is that I would highly advise against using Apple sample projects directly in a production application, especially Reachability. Many of their examples are badly written and, as you've noticed, outdated. I've filed a lot of bugs against them without many results.
That said, one other point is that you should really think twice about relying on Reachability for control logic. If you just want to notify the user when their connection changes or something, okay. But don't rely on what Reachability says to decide whether to try communicating with the network or not. It's often wrong about your network status. Just open up a connection, and if it succeeds great, otherwise you'll get an error response letting you know there's no connection.
EDIT - Regarding your other question about how to tell what IOS a third party app supports. The answer is, unless they've documented it, you might not be able to. Best indicator is usually taking a look at the build target's "Base SDK" and "iOS Deployment Target" settings. Base SDK will be the latest iOS version they've built against, and Deployment Target will be the earliest iOS version they support.
Cheers
I have, after many months of work, finally got my app updated for iOS4.
The first release was complied for iOS3.2 and has been in the AppStore for a while, I was very impressed to see it continued to work and be downloadable for iOS4 users all this time, even though my version failed to compile for iOS4.
However, now I've got the new version (complied for iOS4.2) waiting for review - I'm unsure what will happen to the existing app! If it is used overwritten, what will people with old versions of iOS see? Am I closing the door to anyone without iOS4.2+?
Many thanks
Ben.
p.s. apologies if this has been covered - I did look and failed to find :-)
When you specify the minimum OS required in the bundle, that filters what users will be notified of the upgrade. So users of your app that have yet to upgrade the underlying OS will not get pushed the update.
You can actually specify the target OS Level to an earlier version. The app will be allowed to install on that and any newer version. Generally, Apple is very good about forward-compatibility.
As Peter said, you probably don't want to compile it to only run on 4.2. If you added features that use newer versions of iOS, you can actually do a check prior to calling the method (I've done this with gesture recognizers) to ensure that the running OS version is capable. If you don't validate the OS, the app will simply crash on users with too-old operating systems, which could cause Apple to reject it.
Also, 4.3 is almost out, so you might as well wait a week :)
If your app only supports 4.2+, then only users with a device with 4.2+ iOS will be able to install and use your app. The version currently on the store will be overwritten. In short, yes you are "closing the door" to anyone with a lower version iOS.
I've been working on creating my own iPhone app with source code my company gave me. This code was created with iPhone SDK 3.0. I've worked on it for over a year (I'm a designer so my coding is mostly copy and paste) and to test the app on my iPhone it says I must update my SDK to 4.2. I'm wondering will this break my app? I probably don't have the skills in xcode to upgrade my code if I am required to rewrite parts.
Thanks,
Chris
If none of the code has been deprecated, changed or even removed, chances are good it still runs fine. Most projects run, and if you have used external code (and hopefully noted where you got it from) there might be an update available for that piece of code.
Just set the deployment target to iOS 3.0 in your project settings
here some little explanation: link