I had a question regarding IOS projects and OSX projects on Xcode. Essentially I have a section of code that works under OSX base sdk (its mainly a OSIRIX plug in) and will only work by having an OSX base SDK. The OSX base sdk code just lets me choose images, I also have a section of code that will allow me to process the data from the images, this functions only under an iOS base SDK. Is there way to have two sections of code that function under different base sdk functioning under one .m file?
Please let me know if I am too vague, I am currently very confused on what to do about it.
Related
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.
First of all this question is just theoretical, I know that is not something you should really do.
I was ordering with it's possible to link an iOS project to use it sources code as a library in a OS X project, since iOS project in debug mode produce code for simulator architecture which is the same used in OS X project. I Know that frameworks like UIKit will not be available, but with we link (again I am being theoretical) with an OSX version of the UIKit?
Here is my short assumption on that currently looking more on it.
Application with Swift code bundles Swift specific standard libs with Swift, Apple has changed how standard libraries are shipped. With Objective-C, all of the standard libraries, system frameworks, and the runtime itself, were shipped with the OS. But With Swift, Apple trying to ship a specific version of the standard library with your app.
Please share your thought on that.
Found Interesting - Compatibility Blog
According to that - In fact, you can target back to OS X Mavericks or iOS 7 with that same app. This is possible because Xcode embeds a small Swift runtime library within your app’s bundle. Because the library is embedded, your app uses a consistent version of Swift that runs on past, present, and future OS releases.
Any other discussion warm welcome!
I'm completely confused and I don't know where to start asking questions. I tried googling, but the terminology is confusing and I'm not sure what either of these things do (except for Xcode). Can someone explain like I'm 5?
I'm on the cocos2d-swift website and after reading the getting started section it says "From this point onwards, using SpriteBuilder is optional.". I don't know what they mean by that.
How do each of these correlate with each other?
Also, how is an API Documentation Browser and Code Snippet Manager useful to an everyday iOS Developer?
cocos2d-swift is a framework that enables you to build things like sprite-based games quickly.
SpriteBuilder is a tool that helps you build your own multilayered sprites (images and animations grouped into a single package -- i.e. Mario, a Goomba, a Fireflower fireball, etc.).
Xcode is a developer environment in which you write your source code, compile, distribute, and test.
CocoaPods is a tool that fetches and manages framework/SDK dependancies.
You would use CocoaPods to fetch the cocos2d-swift framework so that you could build a sprite-based game in Xcode using sprites you generated in SpriteBuilder.
Not sure what Cocos2d is, but swift is the latest programming language by Apple for both OS X and iOS development.
http://en.wikipedia.org/wiki/Swift_(programming_language)
SpriteBuilder is a framework used to create games for iOS very quick. Think of it as a game engine.
http://www.spritebuilder.com/about
Xcode is the IDE (integrated development environment) that you use when writing native OS X and iOS applications. It's awesome!
CocoaPods is a way to load in third-party libraries and frameworks without having to manually install them on your own. It also makes it very easy to keep the frameworks up-to-date. Pods also allows your project to be more portable as it's much easier to install an application with multiple dependancies via Pods.
http://cocoapods.org
A documentation browser is good if you want to have access to documentation while offline. However, I almost always use Google to find what I'm looking for regardless of what technology I'm working on. Google is just the best way to search.
Finally, I'd start off with this book. I read the first edition years ago, and made things very easy for me to understand.
http://www.bignerdranch.com/we-write/ios-programming.html
Hope this helps!
Here are some basics:
XCode (A Program)- Most of your iOS development will happen here. Coding, creating the app etc.
Think of an SDK as a suite of commands or tools you can use-API's (API - Application programming interface)
Cocoas2d (An SDK) - Game engine. A software development kit for creating games. you would pull this library of code and tools into xcode to use it.
SpriteBuilder (An SDK) - Suite of tools for building games. Just like Cocoas, you would pull this into xCode to make use of it as you code.
CocoaPods - A tool for linking/loading SDK's into XCode and easily updating them.
Moral of the story: XCode is the software you will use for everything. Everything else are just additional libraries of code you can pull in.
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.