IIRC runtime compilation and linkage to JIT-ed native code is not allowed on iOS. I was wondering does it affect native code that was not compiled on the client machine but a remote build server and deployed and linked to internally. Is the problem "native code generated on the fly" or "native code that has not passed Apple's review process"?
As I know, there's no correct way to dynamic linking in iOS - it's prohibited by Apple.
Also look here please: Can you build dynamic libraries for iOS and load them at runtime?
Related
I'm working on a framework which embeds another framework (from CocoaPods) for error logging on iOS. This is working very well, and I can embed such a framework in an iOS application for testing, codesign everything, and debug on my own device easily. Unfortunately, when attempting to upload such an application to Apple for distribution, I get an error message as such:
Invalid Bundle. The bundle at '<myapp>.app/Frameworks/<myframework>.framework' contains disallowed file 'Frameworks'. With error code STATE_ERROR.VALIDATION_ERROR.90206 for id ***
I'm not sure if this message indicates that I'm not allowed to embed a framework in another framework or what. It seems the automatic codesigning Xcode is doing is not recursing to the deepest embedded framework upload (I have a script to manually sign everything on build). Does anyone have experience with an error like this or know where to look? It seems others have asked questions about embedding frameworks in other frameworks before, but most of these are how to get linking to work or how to properly reference these nested frameworks. My issue is specifically if I am allowed to upload such things to test flight/the app store, and how to do so if it is possible. Most people having this issue seem to have disabled swift support, but none of the projects I'm using have swift code.
Nested bundle cannot include a framework. You can check this apple document.
iOS and tvOS support frameworks and Swift system libraries at the topmost app level; a nested bundle, like an app extension, can’t include a framework.
And there is a warning block that worth being noticed:
If you put content in the wrong location, you may encounter hard-to-debug code signing and distribution problems. These problems aren’t always immediately obvious. For example, when building a Mac app, incorrectly placed code might work during day-to-day development, but might cause problems during notarization.
So that is the reason everything seems normal while running in debug mode but failed at distribution.
Here is the error message:
I checked this solution, but my paths already have that value in Xcode:
Build is failing in iOS #447
The tipsi-stripe library is no longer maintained or supported by the developers. You should instead use the official stripe-react-native library following the migration guide.
After I fixed some bugs and refactored my project which has been release on App Store, it fails to distribute. The Xcode shows the following error message:
Your app contains non-public API usage. Please review the errors, correct them, and resubmit your application.
The app references non-public symbols in Payload/XXX.app/XXX: UICreateCGImageFromIOSurface
XXX is the app name.
I've search the entire project, and didn't find any this keyword (UICreateCGImageFromIOSurface). How can I fix this?
Remove Reveal.framework from your project. This should not be linked in release mode of your binary.
You app contains code not only from sources, but from all statically linked libraries. You have to check all of those for containing private call. Looks like at least Reveal library contains it.
Double check any third-party libraries you are using in your project
I was facing the issue and after checking my pods file, I found that Look Back - Framwork which is available for debug builds only as for as I know. So removing that fixed the issue. Successfully submitted app through Xcode 6.1 for Apple Testflight beta testing :)
Never ship an app linked against the Reveal library. Reveal exposes
your app to deep introspection and will likely cause your app to be
rejected by the Apple review team. Reveal is intended for internal
development and debugging purposes only.
The Reveal service will stop automatically while the iOS host app is
not the frontmost app. It will automatically start again when the app
is re-opened.
Reveal supports inspection of applications compiled against iOS 6 and
later. The iOS Deployment Target build setting must also be 'iOS 6.0'
or later. You may see link errors if this is not the case.
Reveal uses Bonjour to connect with the running iOS application. If
you are running the iOS application on a device, it will need to be
on the same network as the Reveal Mac app to be able to connect with
it. If you have any problems connecting to your application check
your firewall and proxy setting to ensure they are not blocking
communications.
Find out more...
cordova plugin rm cordova-plugin-ionic-webview
cordova plugin add cordova-plugin-ionic-webview#4.1.0
It is stated in http://playcontrol.net/opensource/LuaCocoa/other-luaobjective-c-bridge.html that LuaCocoa supports Mac implementation. Thus, the available framework, luacocoa.framework is compiled for Mac platform.
However, I wanted to try to compile it on iOS platform to see if it works. So, I downloaded LuaCocoa source code and tried to compile it on iOS platform. Obviously, there are errors. I have this:
"target specifies product type 'com.apple.product-type.framework', but there's no such
product type for the 'iphonesimulator' platform"
I believe that is due to iOS unable to run dynamic library.
So my question is: anyone successfully compile luacocoa on iOS platform and is there any chance luacocoa able to be used on iOS platform.
If there are better suggestion to bridge ObjC-Lua, do let me know as well.
Have you tried Wax
It is an Lua - Obj-C bridge for iOS that has been around for a long time.
Here is a nice article about it.
For debugging purposes I am looking for a way that a iOS app (whose source code I have access to) can communicate with a separate OSX app, e.g. via sockets.
Since an iOS app running in the Simulator runs natively on the Mac, by using specially designed iOS simulator frameworks that route I/O through OSX frameworks, there must be a way that I can achieve that with my own code as well.
Simply adding standard OSX frameworks to the project and using them from within the iOS app does not work:
If I try to load a OSX framework that exists already as a iOS framework, the iOS framework will always be preferred, meaning if a framework function is only available on OSX but not in iOS, I can't get to it. If the framework doesn't exist yet, like Carbon.framework, then I can get the linker tries to load it. For instance, if I'd try to get to SysBeep(), which is part of Carbon.framework, the linker then fails with an error msg when it wants to resolve external symbols that point to other libs that are already loaded as a iOS-only lib.
I've also tried loading a OSX specific framework using dlopen(), but that fails just the same.
In other words:
How can my iOS code get access to the OSX-specific libs additionally?
That's a lot of questions at once. Let's go step by step:
For debugging purposes I am looking for a way that a iOS app (whose
source code I have access to) can communicate with a separate OSX app,
e.g. via sockets.
It's definitely possible to use OS X facilities from within the iOS app process running in the simulator. Using plain sockets would be very simple as the BSD library is identical in both iOS and Mac OS. You can simply compile your C code and it would use the underlying OS transparently.
If you wanted to use an Objective-C API like NSURLConnection you can do this as well. In the simulator your app uses the Mac OS version of Foundation and Core Foundation. In most cases you would not recognize this as the API is very similar.
[...] the linker will have trouble keeping things apart due to name space
collisions [...]
It's not really clear what you are trying yo achieve here. As I explained, the simulator process uses proper Mac OS lower level frameworks directly. It does not make sense to link to higher level frameworks like AppKit since the app does not make use of Cocoa desktop components. That's why there is no NSApplication symbol and the app does not instantiate one. Instead it uses the UIApplication class from the simulator's specially crafted UIKit framework located in
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.1.sdk/System/Library/Frameworks/UIKit.framework
[...] Building the above then leads to a linker error [...]
That's because the linker is directed to only look into the iPhoneSimulator SDK where no AppKit is present (using a linker flag like -isysroot <path-to-SDK>).
But at this point it's probably worth asking yourself why you want to link to AppKit in the first place. You can set up you interprocess communication without AppKit.
Oh, and to prove that it must be possible somehow, take a look at RubyMotion [...]
In the simulator event handling is done in the "iOS-Simulator.app" process (which is a Mac OS application). To get at these events from within your simulator process you could probably use Quartz Event Services.