Edit: Selecting Xcode in Finder, getting info, and ticking the box for Open using Rosetta makes things work, but surely there is a better way…
I have an iOS project with a static framework containing three variants in it; ios-armv7_armv7s_arm64, ios-i386_x86_64-simulator, and ios-x86_64-maccatalyst. I do not have any access to the source code for this framework and asking for a new build of the framework is not a practical option. As a result I need to work with the xcframework that I have in hand.
The framework works just fine on my colleagues machines as they are using Intel based Macs. As a new addition to the team I have been given an M1 machine. While I can build to a physical device, building to the simulator fails with missing symbols. This makes complete sense given that the simulator variant doesn't have arm64 in it.
Simply adding a new definition to the info.plist to cover the M1 chip doesn't work as that means there are two simulator definitions. (There are also other issues with this route)
If I duplicate the ios-armv7_armv7s_arm64 folder, add -simulator to the copies name, and replace the existing definition for the simulator framework with info from the ios-armv7_armv7s_arm64 definition I get an error about building for the simulator but linking in a file built for iOS. This means that no matter what I can't simply copy the existing M1 framework to get things going.
The only things I can think of both involve the need to somehow edit the M1 copy of the compiled framework so that it will work on the simulator, and I rather doubt there is a way to do that. If it is possible to do though I would then need to either come up with some nested framework trick that allowed me to have two definitions for the simulator but for two different architectures; or I would need to write a script that used uname -m to decide how to edit the framework's info.plist file (This feels very hacky, but would be the simplest way of making the project 'just work' on both Intel and M1 machines without the need to make manual adjustments and remember not to commit them.
Anyone have any brilliant ideas on how to get this framework working in the simulator without having a new copy built? (I haven't even found a clear method for how it would need to be built to work on both architectures.)
Xcode: 13.3.1
Related
I have a "fat" framework built for iOS, which is being used in a debugging tool built for macOS. Previously I was linking this framework statically, which worked, even though XCode complains about it being built for the simulator (since the architecture is the same). But now, newer versions of the library are dynamic, so that route doesn't work, as the tool is a command line application, which doesn't support embedding frameworks.
I could turn it into an application bundle, it seems, in order to solve that, but I'm not sure what this entails (creating a new project?). I can certainly figure it out but ..
In the meantime, I thought I'd load the library dynamically using dlopen() etc and retrieve the classes/methods I need (I already have some code for this which at least compiles). However, that call fails with the following message:
no suitable image found. Did find:
/<path to library file>: mach-o, but built for simulator (not macOS)
Since linking statically is only a warning and actually works, is there a way to make dlopen work as well?
Recompiling the framework itself is not an option for me in this situation.
Are you considering editing the binary of the dylib framework? If so in the Macho-O header you could try changing LC_VERSION_MIN_IPHONEOS to LC_VERSION_MIN_MACOSX.Probably it won't be enough,but it's a simple change for a quick test. Here's a screenshot comparison of those load commands in MachOView
Also covered the other way round here
I've been running a Xcode project on my iPhone but I haven't upload the binary yet. The thing is that I've lost the code on my Mac (that's what happens when you don't commit con GitHub) and the only thing I still have from the project code is the "app" that the iPhone saved when I run it for the first time. Is there any way to pass the code from the iPhone or see the code?
No. Your code was compiled, linked and packaged to produce the application, and it is the resulting compiled binary that has been installed on your phone.
You may be able to retrieve resources (storyboards, XIBs, images, plists...). For the code, there may be decompilers (not sure if there are any for Objective-C or Swift, though), but they will not reproduce your original code, just code that compiles to the same thing (i.e. without comments, with arbitrary names for local and instance variables, etc.).
Don't you have a Time Machine backup of your project?
I'm very interested in using GStreamer's iOS framework http://docs.gstreamer.com/display/GstSDK/Installing+for+iOS+development for video streaming, but when I add the framework to a blank project and add a few lines of code to take advantage of its powerful features, the final IPA is 27MB. This is just way to big to be adding to my project, what is the best way to go about stripping this down the the bare necessities as I'm sure I'm only using a small percent of the code that is included in the SDK.
Here's a pic showing the package contents of the IPA:
Thanks!
In the gst_ios_main.h you can disable all the plugins that you don't need (make sure to enable linker optimizations so that unused code is removed). If that's not enough, you can build your own stripped down version of the iOS binaries with http://cgit.freedesktop.org/gstreamer/cerbero/ (you need to remove things from the .package and .recipe files to only build what you need). Just disabling things from gst_ios_main.h should be enough in 99% of the cases though.
Note that by default you'll build applications for multiple architectures, as such the resulting application will be rather large. Depending on your use case you can drop some architectures.
On another note, gstreamer.com is providing an completely outdated version of GStreamer and is in no way related to the GStreamer project. The official website is http://gstreamer.freedesktop.org .
SDKs have their source code encapsulated away from you, the user. You get access only to header files. Thus you just can't extract some class from it because you don't have access to the implementation file.
Of course if this library is opensource you can attempt to isolate one class, but sometimes everything is so deeply connected, that it is close to impossible.
I have a large (thousands of files) product that I am porting to iOS. I have an existing build structure that constructs about 50 static libraries that can then be used by a platform-specific [G]UI. Some of the libraries are 3rd-party tools like zip, ICU, and Xerces. The portable build process is managed by GNU autotools, and I have created some shell scripting to build the code for i386 (simulator), armv6 and armv7. All of this is being done on Apple's Lion with the 5.1 iOS SDK and Xcode4.
The problem I have is that it's a pain to bring these libraries into an Xcode4 project. Drag&Dropping the libraries is tedious. I've been resisting creating a "project" for the libraries in Xcode because I already have a cross-platform build system that works. I'd like to have a "simple" way to type in the list of libraries and their location(s); my searches here show solutions for Xcode3, but they don't seem to apply to Xcode4.
I am able to build an iOS app that uses these libraries, but the thrust of my question is really: How do I avoid all the drag&dropping and retain my portable build structure so that others using my libraries aren't tearing their hair out? If this were an iOS-only app, I'd just use Xcode4 for everything, of course. But since it is multi-platform and "portable" I really want to keep the process simple, where "simple" applies to both the maintenance of the packaging and to the user/developer who is working with my libraries.
An alternate question might be: is there a safe way for me to generate Xcode4 meta-files so that the end result of my autotools-driven-build just looks like a native Xcode4 project?
Two thoughts:
1) It use to be the case that Xcode supported AppleScript pretty well - I use to do such tasks with AppleScripts. Early versions of Xcode 4 were quite lacking in this support though. Not sure if you can do it with 4.4 - you might ask on the AppleScript implementors list on Apple's listserv group.
2) If you put all the libraries (or perhaps links) into one folder, then in Xcode click on the Target, BuildPhase, Link Binary with Libraries, tap the + key, navigate to your folder, then select all libraries and tap OK, you're done. [Well, almost, then in the GUI pane on left you need to select them all again and move them into the Frameworks folder, which due to this annoying bug, I keep at the top of my projects.]
We have a fairly rich e-learning app, built mostly using cocos2d. Currently we are in alpha and want to setup our project structure so we can also build a Mac version to target the Mac App store. It is about 80% cocos2d with some intitial screens in UIKit which will have to be ported to Mac (re-written).
What is the recommended setup for targeting both the Mac and iOS app stores from a single code base? I assume the choices are:
Create 2 xCode projects in the same application source code root folder and use each project to build a single target. This would be: Project.xcodeproj and ProjectMac.xcodeproj
Add a new Mac target to our existing iPad application project and then fiddle with target membership to get the desired results. This would be just: Project.xcodeproj
Further complicating the situation is that we currently use cocos2d as a static library for the iOS app. We also have a library called CoreInfrastructure that has a lot of code we use across all our projects. Recently I have figured out that I can create a project to simultaneously build a framework targeting Mac and a library targeting iOS from the same code base. This is done by starting with a framework project and adding a target to build a static lib for iOS.
So just wanted to get everyone's opinion and insight. Anyone know of any caveats to watch out for in the above choices? Anyone who is building for Mac and iOS app stores simultaneously care to share their structure? Adding a target worked on our library code ... is that the way to go for the application as well?
Are there any issues doing archive and distribution builds for either choice?
Thanks in advance.
WWDC session "Sharing code between iOS and OS X" answers all the basic questions in this topic. iWork team presented how they have got away with creating Pages, Keynote and Numbers with shared code base for both iOS and OS X.
The key for their project was using:
separate Xcode targets for iOS and OS X
separate project for the shared code in a form of a .framework
target dependency on the framework from the point above
I encourage to watch the video or read the transcript from this session:
WWDC 2014 Sharing code between iOS and OS X
ASCIIWWDC transcript
I recently used kstenerud's iOS Universal Framework to build a shared framework codebase that works for both iOS and Mac apps. I just needed to manually add a target for a Cocoa framework after I had created a project for an iOS framework. That way I can develop the sharable code once in the framework and link it in both the iOS and Mac apps. You can even make the framework contain UIKit-specific code for your iOS app and AppKit-specific code for your Mac apps. I wrote about it in my blog if you are interested.
For the applications use two separate projects. Using multiple targets for iOS and Mac in one project is very useful if they are sharing a library or framework. However, in your top level application almost nothing is shared. The UIKit code will need to be totally rewritten to use AppKit, the dependencies will be different, and even most of the project settings will vary.
Of course if you really want to see everything at once you can put both platform specific application projects and all the shared dependent library/framework projects in a single workspace. This is more a question of work style. If you want to switch back and forth between the two frequently this makes the most sense. If you want to simplify what you are looking at you can put them in separate workspaces that share many of the same projects. Separate workspaces has the disadvantage that a project can only be open in one workspace at a time so you effectively can only work on one at a time.
I just use multi-platform static library targets for the shared sources. You will need to expand that to the dependencies, however. If you have platform dependent implementations, you may want to create supplemental export libraries for those symbols.
So your structure might take this form:
CoreInfrastructure - cross platform static library.
PlatShared - cross platform static library.
PlatSpecific-OS X - OS X static library (or framework).
PlatSpecific-iOS - iOS static library.
The OS X app links to CoreInfrastructure, PlatShared, PlatSpecific-OSX, Cocos for OS X, and system libs.
The iOS app links to CoreInfrastructure, PlatShared, PlatSpecific-iOS, Cocos for iOS, and sys libs.
Problem (I've found) is, there are a lot of people who have not had much/any experience developing and maintaining complex project structures in Xcode. It's a pain (IMO) to setup duplicate targets, and properly maintain them as they grow -- even when they all refer to the same source files. That's why i prefer minimal targets and proper dependency structure.