I discovered that all the Swift libraries (libswiftCore.dylib, libswiftCoreGraphics.dylib,...) exist twice in the IPA. After decompressing the IPA, there is one version of theses libraries inside the folder SwiftSupport and the same files again inside Payload/Frameworks.
As far as I found out, the SwiftSupport folder is always generted by Xcode when a Swift-project is built. But where do the Swift libraries in Payload/Frameworks come from and how can I get rid of them?
I think that if your code already uses Swift, you have no set the Flag "Embedded Content contains Swift code" in Build Options to NO, otherwise Xcode will add the libraries because it thinks that you use some frameworks that have swift code
I am experiencing the same issue. I have read some answers which suggest that it isn't a big deal and I have to say that it looks like it isn't.
My app contains 3 targets - main app and 2 today extensions. When I create an archive its size is a whooping 126 MB. Most of it is Swift support libraries which are about 45 MB in my case and they are included twice.
However, when I check the binary size through test flight it is 23.6 MB. Now, this is still a lot considering that my application is a simple utility.
However, it is not too much if you take into account that Swift libraries have to be included. So far I would say that even though these libraries are included twice in the IPA they are not included twice in the actual binary.
This obviously doesn't answer the original question and I am also eagerly waiting for someone to come up with the exact solution, but it might be helpful.
I've found that playing around with 'Embedded content contains Swift' value yielded some good results, and was actually crucial for my app with an Apple Watch extension to pass validation.
I have written an answer about the details for the Apple Watch fix here.
Related
I'm adapting an (apparently outdated) Cordova plugin for use in my app (PhoneRTC if you're curious).
As a Linux/CLI guy at heart I've been struggling with XCode for a day, and I managed to iron out most of the deprecated code using a lot of Google and some blind guessing. However, now I'm stuck with a final error during the linking phase:
"Undefined symbols for architechture arm64: "_utf8_nextCharSafeBody", referenced from: [snip]"
The plugin's original installation instructions mention linking the binary to the library libicucore.dylib, but this seems to have been removed in the latest XCode (there are references of the same name with .tbh extensions available but these aren't valid for that dialog - even though I can select them, but whatever).
Some more Googling offered suggestions for linking various *.frameworks instead, but to no avail - the error remains.
Does anyone have any idea what I need to link to to make this function available? Or if it's permanently removed I'd also like to know, although that would involve rebuilding the binaries which wouldn't be something I'm looking forward to...
Or if you don't know, would there be a way to grep through Apple's libraries somehow to see which one is supposed to be defining a missing symbol?
(Needless to say, IF I can get this working it's going to be forked from the original repo and donated back to the community :))
So, I'm not sure what I changed exactly, but suddenly I could add libicucore.tbh as a linked library. I probably changed the build target or something, but in any case the linking error disappeared (to be replaced by a signing error because XCode, but that I can solve).
I have an Xcode project I want to archive.
However, the archive takes a very long time and trows an error: Xcode can not compile a file with about 19.000 lines.
Is there a limit on the number of lines Xcode can compile?
Is there a way to actually get Xcode to compile this file?
EDIT:
I have to note that this file only contains some parsed content, i.e. is a data model which can not be split.
I know it could be extracted into a database of some sort, but the question is really about Xcode and its compiling behaviour.
I changed my project to have <19,000 lines however a similar error still persisted!
what worked for me in Xcode5 after all was to change the Build Settings: Set "optimisation level" for RELEASE (or all) to NONE. worked wonders.
Divide & Conquer
What kind of code is that in a single class/file?
You could have broken that code into modules by creating other classes/objects. That would be simpler to understand and manage.
I'm having an issue with xcode. My project has a lexer which should be created (from lexer.l) before compiling anything. Flex should create two files from lexer.l: lexer.c and lexer.h. The latter is included in some other files. What happens now is Xcode does not process lexer.l and then complains about missing lexer.h. lexer.l is include in the compile sources list under build phases. Any thoughts?
One year late I can provide a solution. Maybe someone else can use it.
As I read on some answer on SO Xcode needs some special file extensions to map them to the different programming languages. When you want to compile c++ code f.e. you have to give the lexfile the ending .lpp. Xcode will handle the rest
I'm still not 100% sure with the framework linking process, but from what I've seen here before nobody has asked a similar question, perhaps because this could be a silly question, but I'll give it a go anyway.
In my current X-Code project, I'm using a custom framework, say example.framework. At the moment, as far as I'm aware of, in order for the program to function with the framework, I need to have it either in /Library/Frameworks, or I need to have it copied into the bundle resources in the build phase.
Would anybody know about adding a framework to a project in a way that it gets compiled into the executable, so I don't have to include the raw framework with the app? I'd rather not share the whole framework...
Thank you in advance! Any suggestions are also welcome!
A Mac OS X framework is basically a shared library, meaning it's a separate binary.
Basically, when your main executable is launched, the OS will load the framework/dylib into memory, and map the symbols, so your main executable can access them.
Note that a framework/dylib (bundled into the application or not), does not need to contain the header files, as those are only needed at compilation time.
With Xcode, you can actually decide whether or not to include the header files, when you are copying the framework to its installation directory (see your build phases).
If you don't copy header files, people won't be able to use your framework/dylib (unless they reverse-engineer it, of course).
If you still think a framework is not suitable for your needs, you may want to create a static library instead.
A static library is a separate object file (usually .a) that is «included» with your final binary, at link time.
This way, you only have a single binary file, containing the code from the library and from your project.
The documentation for the project says just add the framework and the linker flags and you are good to go. Hours and hours of wasted time later, I have figured out that that's not true. If you do that, the project does not see the header files. You have to put the framework somewhere were the compiler will find the headers. In my case, that worked when I dropped the framework into /Developer/Library/Frameworks and then told it to recurse in searching that framework directory (do not fiddle around with the headers search directories).
Then the problem I get is that the link fails with the message:
ld: framework not found OCHamcrestIOS
I noticed that the documentation for the project says that it was updated for Xcode 4. I pulled down the binary of the framework after checking out the code and wasting a ton of time unable to build the IOS version of the framework.
The documentation is here.
I also noticed in that documentation that the cocoa instructions tell you to put a copy files phase into the build. I tried that. Didn't change the outcome.
The last time I fell into a sink hole it was because the library was C++ code. Maybe that's still the problem.
Barring a rapid solution here, I am going to go back to using STAsserts, as sickening as that prospect is, this is far, far worse.
Update: reinstalled Xcode. Still doesn't work. There are cheap ways to make this work, like add the header files to the project. Did a blog post about this that brought out a person with the same experience.
I use a number of frameworks in my projects. Some from other people and some are mine. Looking at the documentation I would suggest that the copy phase stuff is not for iOS development. So I would not do that. I downloaded the latest zip from https://github.com/jonreid/OCHamcrest and it appears to contain a ready to go iOS static library. (Not on my mac so I cannot test to confirm).
Anyway, the way I include static libs is to
Select the project (XCode 4).
Select the target I want to add the library to.
Select the Build phases tab.
Expand Link binary with Libraries.
Click the [+] button to add a framework.
Click the [Add Other ...] button and navigate to the directory containing the <lib>.framework directory and select that.
Thats all. The targets search paths will be updated to include the framework directory and the framework will be listed on the left under the project. Expanding it will show the headers.
The problem you mention sound like a couple of things. Firstly the framework not found sounds like the framework has not been included in the target. When you select the framework in the project list on the left, you should be able to see it's Target Membership displayed on the right. Check it's on for the target you are compiling.
Secondly building frameworks is not a trivial task so don't attempt it unless you have the scripts to do it. I say this because building a iOS static framework means compiling for both simulator and devices, combining the compiled lib files into a universal one, and then storing it and the header in a specific directory strucuture.
The downloaded zip from OCHamcrest though, appears to have the correct OCHamcrestiOS.framework in it. So if you store that directory somewhere and link to it using the steps I've outlined above it should work just fine.
So the solution I adopted for now, after much thrashing around, was to include the framework in the project.
Create a group inside the Xcode project called Third Party.
Link it to a folder called thirdparty.
Go to the Add Files in Xcode and pick the framework.
Drag it over to the dependencies.
Run the tests, they pass!
This is maybe preferable anyway because referencing it in /System/Library/Frameworks would present some versioning issues, and this can be setup very quickly. Furthermore, we have a continuous integration server, and having to get in there and sync versions whenever something changes is not so great.
Thanks for checking it out, Derek.