I'd like to create one framework for reuse on iOS (including the simulator) and OS X.
I've seen a SO question that referenced this: https://colemancda.github.io/programming/2015/02/11/universal-ios-osx-framework/ - however I get an error about x86-64 not being supported.
I'm not sure if that's the best way to go about it. Ideally I'd have one project/workspace that I can export one framework to other projects/workspaces where I can use any public class or method. If I had to generate different framework's for each platform from the same project that wouldn't be a big deal either - the goal is to just have to maintain one project that can be re used on each platform.
I've been at this for longer than I'd care to admit so thank you for reading.
Related
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
I have not used Xamarin before, I'm coming from a native development background.
I have a question about the feasibility of binding a native iOS library written in Swift, in order to use it in an Xamarin project. Is this possible and more importantly is it possible to do without any access to a Mac OS computer?
As a side question, is Objective-C library binding doable without Mac OS?
To do the entire process: No.
You can create a Xamarin Binding project from within Visual Studio, but there are a lot of dependencies you will need that you can only get by having access to a macOS.
1 - If you don't have the compiled and fat library you will need a macOS to build using Xcode and use Lipo to create the fat library.
2 - Supposing you already have it, you will need to create the ApiDefinition.cs, to do so you might use Objective Sharpie (macOS only). You can get around it by creating it manually, but unless you are binding a very tiny library - just for the sake of proving the point - you will not want to do so.
Those two apply to any Xamarin.iOS Binding, as it is the same process for Objective-C Bindings
3 - For Swift Bindings you will also need to include all Swift dependencies inside SwiftSupport folder inside your IPA file. This step is required before publishing the App, not creating the binding - I have only tried to do so using a shell script. But for this case you need a macOS to publish the app to App Store as well.
So just to prove the point: Maybe.
I'm developing an iOS SDK that integrates other SDKs (Facebook SDK 3.5, for example).
To prevent collisions and allow my customers to import those SDKs as well, I want to rename all of the classes/enums in my code (for example, rename FBSession to RDFBSession, etc).
Is there an easy way to do this instead of going class-by-class and using Xcode's rename feature?
Apple provide a command-line tool called tops(1) that is designed for scripting large-scale code refactoring (renaming C functions, Objective-C methods, classes, and other tokens):
tops -verbose replace "FBSession" with "RDFBSession" Sources/*.[hm]
If you have a lot of replacements, you can put all of the replace... commands into a file that you pass with the -scriptfile option. The man page has more information on the more complex commands/options (and examples).
Xcode also offers textual Search and Replace. This will be faster than individual refactors, but it is ultimately less automated. You can make the step by step refactoring faster by first minimizing the project to the relevant dependencies/sources (if possible).
However, renaming the declarations in a library will not alter the symbol names of its associated binary. If it is distributed with a binary, then renaming will just result in linker errors or (in some cases) runtime errors.
The best idea if you need to use a 3rd party library which your clients might also use is to simply inform them they need to link the library with their app, then publish the version(s) the current release supports so they know they have some extra testing if they go too far ahead with some libraries.
I think that a better approach than simply renaming your classes would be to download Facebook's open source code, rename the classes there and compile a new static library with a set of renamed header files. Then you can be sure that no collisions occur and that you're using symbols that you named yourself.
I must warn you though - working like this may make updating the SDK a nightmare regardless of how you tackle this specific issue.
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.
I have my first iOS application under my belt (a relatively straightforward iPad app, to be released in a month or so), but now I'm moving on to something more ambitious, and could use some advice.
My next project will actually be two distinct but closely related iPad applications that will share quite a bit of core functionality and a common data format. So my instinct is to develop these two applications in conjunction with the development of a core framework shared by both, and I'd like this shared framework to use CoreData and also provide GUI elements (NIBs, view controllers) that can be used by the respective apps. My further instinct therefore is to create 3 Xcode projects: one iOS app project for app A, a second iOS app project for app B, and a third, CocoaTouch framework project for the shared framework.
Questions:
1) Is this the right way to structure my development, or is there a better way to do concurrent development of two closely related apps and a shared framework?
2) Can a framework use CoreData? (I ask this because when creating a CocoaTouch framework project in Xcode one isn't offered the option of having it use CoreData -- nor the option of having units tests -- as one is when creating an iOS app project).
3) Is there a way to "convert" an iOS app project into a framework project, or, perhaps preferably, rather to build an app project into a framework target? That would let me create the framework project with all the Xcode setup freebies (NIBs, core data, etc.), instead of adding all that stuff manually.
Thanks!
Carl
To answer question one, I wouldn't work this way. I would create one project with three targets, two app targets and a framework target. Maybe in the future I would move the framework to its own project when it had stabilized and if I was going to use it for even more iOS apps. Having all the targets in the same project reduce synchronization problems when working on code shared among the targets.
To answer question two, Xcode just doesn't include the template support to add Core Data and unit tests to a starter framework project. I see no reason why you can't use Core Data in a framework.
To answer question three, just add a framework target to your iOS app project, and move the appropriate portions of your iOS app to the framework.