So on iOS Apple won't let you release an application that has a dynamic library (dylib). (Xcode won't compile it although there are workarounds, and the app store won't approve it.)
We have an SDK that we are currently moving from Windows to iOS. On Windows, we statically link all of our dependencies into one dll, so we only have to provide 1 file to anyone using the dll, so we don't have to publicly release all of the libraries that we are using and to keep the size of that file small, since any parts of those libraries that we aren't using get compiled out.
On iOS, since it's not possible to release an application that loads a dynamic library, we would be forced to ship a framework or something like that, which includes all of the libraries that we link against. The developer consuming our sdk would then compile our lib with all of its dependencies into their application.
This would let anyone using our SDK know what libraries we're using and would increase the size of our deliverable, since it would have to include full version of all the libraries we're linking against. (At least with a framework we would still only be providing 1 "file".)
Is there any way that Apple allows to avoid letting everyone know what libraries we're using?
Related
I have an application Unity that uses the iOS static library. Then this application Unity is build in XCode. I found several utilities that allow you to obfuscate the library in the application. for example this - PPiOS-Rename.
I carefully read their documentation "Obfuscate Static Libraries", but at the time of building, the iOS static library are already "hidden in the root" of the Unity app, and XCode cannot obfuscate this.
So I need to first obfuscate the library and then add it to the application. or is it not possible?
In my understanding of the documentation PPiOS-Rename stays an external tool, just the files *.plist can be added into the releases, for being able to use the tool on the compiled releases.
I might be completely wrong about it, especially as without iOS I can't test it, but I'd check if my statement is right and if you can omit the step to include the library in your compiled releases.
About handling of *.plist files, follow the instructions on the linked page, I'm not sure if you have one or more in the end. As it doesn't seem relevant to the core of your question, I never verified it deeper.
I feel weird about difference between advantage of dynamic linking library in Window or Linux and iOS.
⬇️ sentences below are to prove why I feel weird.
I learned that library can divided into static library and dynamic library
Advantage of using dynamic library is allow other application to use same dynamic library ( in Window, .dll file) so that each of application memory usage can be reduce and it can be easiar to redistribute dynamic library rather than to redistribute application.
Actually I could have experienced "there is no XXX.dll file" in using some applications
And in Xcode, when to create new project, we can choice framework and static library in framework & library.
And after creating project, we can choice how to being what Mach-O Type is like "Executable, Dynamic Library, Static Library" etc..
So, I think that if I choice Mach-O type with Dynamic Library, the project will be compiled using dynamic linking library in linking way.
⬇️ I really wonder about.
But like in Window, Could iOS user downloads .so file in their iPhone in order to work normally app or update dynamic library?
Could others app launched in iPhone use same dynamic library ?
Because I could't experience about that.
If it(1,2) can't be, why to use dynamic library even we couldn't get actual advantage of using dynamic library like in Window or Linux ?
Your understanding of dynamic and static libraries is correct.
Static Linking
The compiled source code (object code, the .o files) and the compiled library code are combined into a single executable [1]
Dynamic Linking
The compiled source code (object code) and the library code are not combined together. The references to the dynamically linked library are resolved at runtime while the app launches or while running (the second part is not applicable in the case of iOS Apps) [1]
Q1
iOS borrows heavily from MacOS on how its applications work. Executables in both the OSes are Mach-O files. Now, on macOS dynamically linked libraries or dylibs are intended and designed to be updated without having to update the entire app. And by design, this is possible in iOS as well. What prevents this is Apple's guidelines restricting apps from downloading executable code from the internet. Any new update has to go through their review process. [2]
Q2
Yes, some dynamically linked libraries are shared across apps. However, they are created and updated by Apple through iOS updates. All Apple frameworks like UIKit, SceneKit, etc are examples of this. This is why these frameworks are weakly linked in Xcode with the option 'Do Not Embed'
Q3
Using your own dylibs are not completely pointless. If you ship extensions in your app, then dylibs are an excellent option to share code between the app and extensions without increasing the binary size. In this case, the executables share the same library. [3]
[1] https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html#//apple_ref/doc/uid/TP40001873-SW1
[2] https://developer.apple.com/app-store/review/guidelines/#app-completeness#2.5.2
[3] https://developer.apple.com/forums/thread/73802
[Vocabulary]
But like in Window, Could iOS user downloads .so file in their iPhone in order to work normally app or update dynamic library?
Dynamic library in iOS world is .dylib and they are updated along with OS updates. As an example Swift standard library[About] has a copy in every app before ABI OS stability[About]. But you cannot still download .dylib manually
Could others app launched in iPhone use same dynamic library ?
Of course. For example core libraries(runtime(Objective-C, Swift), Foundation)... distributed as dynamic libraries to share binaries through different applications and processes(IPC)
If it(1,2) can't be, why to use dynamic library even we couldn't get actual advantage of using dynamic library like in Window or Linux ?
You are able to create a dynamic framework with dynamic library inside(from iOS v8) which can be used for extensions(share some code inside different application)
I'm distributing libraries for other developers to use (http://empiric.al). I've noticed that between swift versions, even 2.0 to 2.1, I'll get Module file was created by a (newer/older) version of the compiler.
I need to be distribute in a future-proof way.
How can I make sure my compiled frameworks can be used by newer versions of Swift in the future so I don't have to recompile as soon as Apple puts a new beta out?
From Apple's website:
Binary Compatibility and Frameworks
While your app’s runtime compatibility is ensured, the Swift language
itself will continue to evolve, and the binary interface will also
change. To be safe, all components of your app should be built with
the same version of Xcode and the Swift compiler to ensure that they
work together.
This means that frameworks need to be managed carefully. For instance,
if your project uses frameworks to share code with an embedded
extension, you will want to build the frameworks, app, and extensions
together. It would be dangerous to rely upon binary frameworks that
use Swift — especially from third parties. As Swift changes, those
frameworks will be incompatible with the rest of your app. When the
binary interface stabilizes in a year or two, the Swift runtime will
become part of the host OS and this limitation will no longer exist.
Until the Swift ABI (application binary interface) stabilises (I'm guessing another year or two) the only way to distribute libraries that will work across different Xcode versions is to distribute the source code. Cocoa pods and Carthage are both good tools for making library distribution easier but for Swift code they will still rely on source code being available.
It might be possible to have an Cocoapod that detects the version of Xcode it is run with and then downloads and provides the correct build of your library but you will still need to build the libraries for all Xcode versions that you want to support and recompile every time Apple release a new Xcode but at least the user wouldn't need to download a new version manually.
The first thing I tried is to create a static library but later I found out that it's not supported yet. Apple Xcode Beta 4 Release Notes:
Xcode does not support building static libraries that include Swift
code. (17181019)
I was hoping that Apple will be able to add this in the next Beta release or the GA version but I read the following on their blog:
While your app’s runtime
compatibility is ensured, the Swift language itself will continue to
evolve, and the binary interface will also change. To be safe, all
components of your app should be built with the same version of Xcode
and the Swift compiler to ensure that they work together.
This means that frameworks need to be managed carefully. For instance,
if your project uses frameworks to share code with an embedded
extension, you will want to build the frameworks, app, and extensions
together. It would be dangerous to rely upon binary frameworks that
use Swift — especially from third parties. As Swift changes, those
frameworks will be incompatible with the rest of your app. When the
binary interface stabilizes in a year or two, the Swift runtime will
become part of the host OS and this limitation will no longer exist.
The news is really alarming for me a person who writes components for other developers to use and include in their apps. Is this means that I have to distribute the source code or wait for two years?. Is there any other way to distribute the library without exposing the code (company policy)?
Update:
Is Swift code obfuscation an option at this point ?
Swift is beta now, and even for 1.0 Apple has been pretty clear they're after a restricted feature set -- better to do a small number of things well than to try to do everything.
So for now, there's no way to distribute binary static libraries. Presumably that'll change sometime after Swift 1.0. For now, you can:
Distribute source
Ship a binary framework (instead of a library) if you're okay with the ABI being fragile
Use ObjC for library code
You can always combine approaches, too: e.g., implement the critical (secret) details of your library in ObjC, and ship Swift source that wraps it in a nice Swift API.
Obfuscating code written in a language that's very much subject to change sounds like a recipe for a maintenance nightmare.
I believe the whole approach is wrong. You cannot do something that is not (yet) doable by the technology you are trying to use.
Rationale: Swift is a new language, currently in Beta, and therefore changing. As I see it, this fact means not only that you are not able to ship static libraries, but that (real) developers will not be actually use third-party static libraries. What's the actual use of a library that may not work in the next release of the compiler? The issue gets bigger if you whant to use more than one library, because they might not be compatible! Therefore, even if you would be able to ship static libraries, they wouldn't be actually useful for production environment. So, what's the point?
Suggestion: write your static libraries in Objective-C (or C or whatever "non-beta"). Developers who need third-party libraries (e.g. yours) shouldn't expect them to be written in Swift until Swift is stable. You don't use experimental materials to build real bridges, right? You use well-tested, predictable ones.
From Xcode 9 beta 4, Xcode supports static library with Swift sources.
I have a C lib and dll file from windows application. No source code with me.
Is it possible to use that in an IOS application.
I have seen mixed responses and am confused.
If we have source code , i think we need to create dylib and then we can use the same after including relevant header file.
Please share any expert ideas to guide me in right direction.
Appreciate your help .
mia
Dynamic Libraries are not permitted on iOS to begin with, but above that, the DLL file format is not recognized by Darwin or the underlying XNU Kernel at all, as the binary format is different.
Windows APIs are not usable on the Darwin OS either (Both Mac OS X and iOS are wrappers around the basic Darwin OS). You will need to rewrite the code from the DLL to use the POSIX and/or Objective-C APIs and compile it as a static library to use it.
You need to get a iOS compatible library, no other way around it. There are several reasons:
iOS doesn't support DLLs as they are windows format, but moreover, you can't use any dynamic library on iOS, as Apple restricts it.
DLLs are usually for intel CPUs, while iOS devices have ARM CPUs.
Most dlls are calling windows APIs - are you sure this one's not?
No. If you all you have is a compiled binary DLL, there is no way to use it on iOS. Unless you happen to have an ARM DLL for the upcoming Windows 8, your DLL contains either x86 or x86-64 machine code (or maybe IA64 if you have a lot of money), which absolutely will not run on iOS devices, which are all ARM architectures. Plus many more reasons.
If you have the source code, you can recompile it for iOS, either directly into your app, as a static library that can be linked in with your app, or as a dynamic library as part of a framework. But in all cases, you need to recompile it from source code using the iOS compiler.
You are going to have to recompile it as a static library (.a file). Apple doesn't allow dynamic libraries except for their own frameworks (so you can't compile it as a dylib).