This question comes from this other one I asked earlier: Calling custom Objective-C from a pyobjc application?
I want to re-use a small part of the app logic from my iPhone app in its server-side component, which runs on OSX. Based on what I was told in the other question, it looks like I need to compile a "framework" for both iOS and OSX from this little piece of app logic.
If we assume that I am able to isolate all the code that is to be in this framework into a single .h/.m pair of files that has no other non-Cocoa dependencies, what would be the easiest way in XCode to build this framework for each architecture and avoid double-coding all this logic on the server?
I tried adding a new OSX framework build target to my iPhone project, but this doesn't get very far and XCode bails out pretty quickly with:
target specifies product type 'com.apple.product-type.framework', but there's no such product type for the 'iphonesimulator' platform
Any help much appreciated, as I am currently dupe-implementing to keep things moving forward, but this is pretty obviously becoming a huge waste of time and source of errors when the implementations become slightly out-of-sync.
Depends on what you used in your custom class. If you did not use anything from UIKit / AppKit then the class is probably going to live well on either platform, otherwise, you’d have to use target conditionals and include separate code specially written for both platforms.
You can have multiple targets in one Xcode project, their Base SDK set separately for the Mac / iDevices.
Adam's comment to my original question answers this question. Although still interested to see if there is a way to do it all from a single XCode project, the solution I have now is plenty good enough for what I wanted to achieve.
Related
Over the last few months I've come across various chatter of external/private libraries not being allowed in iPhone apps.[Just to be clear, this is not something thats going to come, its something I was wrongly under the impression that already exists.]
I was looking at the WunderRadio source: http://www.wunderradio.com/code.html
and I noticed they have 3+ .a files in there project.
libcCommon.a liblibmms.a and libffmpegLib.a are the ones I'm looking at.
Have I been misinformed about the use of this kinda of libraries in iPhone projects? Will Apple accept and approve projects that are using them? If so what is it thats not allowed? Is it just use of Apples own private and undocumented libraries, but you are allowed to include your own?
Many Thanks,
-Code
Static libraries have always been allowed for iOS development and there is no sign that position is going to change at any point (why would it?). Dynamic libraries are not allowed and will result in the rejection of your app.
I think they'd be crazy to do that.
There are so many 3rd party libraries out there that it would pretty much kill the developer crowd they've got now. Imagine if you had to write every library over, from scratch? That's nuts...
Of course, I have no proof one way or another. I just think they'd be insane to try and do that.
.a files are called static libraries. When you build your code, they essentially get compiled in at build time. These are definitely allowed by Apple. In fact, XCode provides a template for a "Cocoa Touch Static Library" when creating a new project.
.dylib files on the other hand are dynamic libraries and are not allowed by Apple. They are separate code files that can be shared by multiple applications as their code gets brought in to your app at run time.
Saurik (the guy who created Cydia) solved this issue by creating Mobile Substrate for jailbroken iPhones. It allows devs to create dynamic libraries in order to alter the functionality of existing Apple classes.
Hope this clears the issue up.
if mono touch is available than why we should use mac environment(sdk,xcode+Interface Builder)?
what are the disadvantage of monotouch compare to xcode?
I always prefer working in the language that is most philosophically aligned with the platform I am developing for.
That is to say, the frameworks the whole platform is built around were written for and in Objective-C. As such, if you are working in Objective-C yourself for a while you understand why things are built the way they are, and can also anticipate calls that might exist or behaviors.
Just as I would not develop for Windows Phone 7 in anything but Silverlight, I would not program the iPhone in anything but Objective-C in order to get the most out of the platform. New language? That's a benefit as people should learn new languages now and then anyway. And it's not like it saves you that much time to use a language you already know since a large majority of your time will be spent learning the frameworks (which MonoTouch lets you call into).
I feel like this needs an answer from the MT camp, too.
Why eat fish, if you can have meat? Why speak German, if English is understood? Why watch CNN if there is FOX? Why vote vote for the Republicans if there are the Democrats? Why...? And so on.
It is your choice! If you have worked with C# for a long time and want to have quick results on iOS, go MonoTouch. Especially if you have a collection of APIs or methods you can reuse, MT is the way to go. If you want to learn a new language (ObjC), go for it. Even if you use MT in the end, knowing ObjC is somehow crucial because it helps you understand why things work as they do.
Hello here is my personal opinion,
I've also been on .Net world for a while, when iPhone launched the ability to create native apps, it called my whole attention and i really tried to learn objc, i took 2 books and started trying and trying and trying like for a month and then I left iPHone programming due to you had to make tons of things than on .NET was a line away for example the GC.
When Miguel de Icaza launched MonoTouch i gave it a try and i realized that most of my previously done code was fully funcional (i've always tried to separate ui code from business code) and this is really the point of .NET on the iPhone, to bring most of your already done business logic to the device.
Also on objc you wont find anything like LINQ or var keyword, consuming web services on MonoTouch its just a few clicks away etc.
If you want to target the Android platform there is also MonoDroid (monodroid.net) wich its coming out later this year the stable release, you can give it a try right now on the beta state. Also if you want to target Mac OSX there is MonoMac. So you can share class libs between all this 3 platforms (also al mono/.net supported ones) without hassle not to mention it will work on windows too and viceversa (when possible) (Also dont forget about WP7).
The only thing you will need to worry about its the UI but most of your business logic should work. here is a complete list of .NET Assemblies supported in MonoTouch http://monotouch.net/Documentation/Assemblies and also MonoTouch exposes a C#/CIL binding to all the CocoaTouch APIs.
Also the support of the MonoTouch team is awesome you can just get on IRC ans ask a question and it will be answered right away, mailing list too :)
I really enjoy MonoTouch, i know that no language is perfect for all tasks, and Objective-C is no exception.
Every example, tutorial, and piece of documentation will be written in Objective-C, and mono will just be calling into Objective-C code under the hood. If you really feel like C# is worth mentally translating everything, and adding an extra layer in your code, go for it I guess.
As a C# developer, I've found Objective-C to be horribly painful to become confident with. It's taken about two months, and two excellent resources to get to this stage.
Get your Visa card out, you'll need to spend a total of $54.
1. The free Stanford "Developing apps for iOS" lectures.
Pure brilliance, and it makes learning Objective-C very clear.
http://itunes.apple.com/us/itunes-u/developing-apps-for-ios-sd/id395631522
2. The iOS Apprentice series.
This is where you'll need to cough up the $54. It teaches you, step by step, how to program in Objective-C, and the apps you build are actually pretty impressive. Part 1 (of the 4 parts) is completely free, so you can give it a go before parting with any cash.
http://www.raywenderlich.com/store/ios-apprentice
I've yet to find any iOS books which match the clarity and friendliness of these two resources.
Finally, don't buy any books unless they specifically say that they're for iOS5 and XCode 4. This latest version of XCode is simply too different to make them useful.
Disclaimer: I don't work for any of the resources mentioned in this thread !
Is it possible to create an own obj-C Cocoa Touch framework which can be used by other developers? And furthermore can you protect this framework?
I've created templates for Xcode 4 that allow you to build universal iOS frameworks (which work in both device and simulator).
Once the templates are installed, you simply select "Static iOS Framework" when creating a new project and it does the rest. It also works with unit tests.
https://github.com/kstenerud/iOS-Universal-Framework
You can create a static library. There is an option in the XCode project chooser to do this. You'll have to distribute the compiled static library file and the header files to users of your library. Your actual implementation files (.m) do not need to be distributed.
GHUnit does a good job of this - packaging up the libraries for both simulator and device - so I recommend looking at this project. (I also recommend using this library for unit testing :-)
The frameworks in Objective C are typically just C / ObjC code and a bunch of classes, nothing amazingly special. As such, you can create your own if you'd like, and then just include that in your project when you build it. The iPhone doesn't care about the difference, it just knows to put all that code into your app, along with everything else.
Have a look at the Framework Programming Guide on Apple's website. It will get you started. Essentially what you'll do is create a Framework project in XCode and then go from there.
As for "protecting" your framework, I assume you mean making your code unreadable. I'm not sure if and how you can do this, but perhaps Apple's guide will say something about it.
Yes you can create frameworks for use with Cocoa Touch.
However there are these caveats:
has to be a statically linked libary, no dynamic loading (dyld) for us
should be a combined (lipo) library for i386 (simulator), arm6 and arm7
you need to hack a bundle project into a framework
you should embed (small and few) images into the library so that the developer does not have to mess around with resources but just drags/drops it into his project
... or if you have large and many images build a bundle with these
I have guides for these things on my site.
1+2 = http://www.drobnik.com/touch/2010/04/universal-static-libraries/
The other links you have to google because this site does not let me post more than one URL.
You could make a static library available as binary (i.e. rudimentary "protection") to third parties, but not a dynamic one, as Apple's App Store policy prevents dynamic linking.
Take a look at a worked example for static libraries given at
this site
If you're going to do it, in my opinion JSON.framework is a great example to follow. To hide/obfuscate the source code is a different story, and a different question entirely,
When creating a new project, navigate to iOS > Framework & Library > Cocoa Touch Framework, it's as simple as that. When you are successfully compile, .framework will be created under Products folder in XCode. Right click to show in Finder, and you can find the output.
It's unlikely this will work the way you want it to because the other developers won't be able to use your framework. This StackOverflow Question explains why.
I'm still getting my feet wet with the iPhone SDK, but I'm wondering if it would be possible to get the ConnectionKit framework working for an iPhone app. I know it was developed for the desktop OS, so I'm not sure what sort of dependencies it has and whether or not it could be shoehorned into the iPhone OS.
In my case, I would like to use its FTP functionality, though having access to this entire framework could prove useful for future projects as well.
Any ideas or experience trying this?
In case it helps, here's the official ConnectionKit site: http://opensource.utr-software.com/connection/
The site was a little light on documentation.
The big question is what Cocoa classes it depends on. Since it is doesn't include any UI code, it should be based on Foundation classes. Foundation in Cocoa Touch is similar to, but not exactly the same as on OS X. Just check out what classes it uses.
The other obstacle is building the framework as a static library. Since the iPhone does not support frameworks/dynamic libraries, you have to build a static library to use it in your code.
That should help get you started.
There are two primary issues. One is static library and other is NSHost class that is supported by cocoa - but not cocoa touch. First one is doable - but the second one is doable if and only if you are familiar with Mac OS networking internals.
The error I'm getting:
in /Users/robert/Documents/funWithFrameworks/build/Debug-iphonesimulator/funWithFrameworks.framework/funWithFrameworks, can't link with a main executable
Cliff notes:
trying to include framework
doesn't want to link
More detail:
I'm developing for a mobile device... hint, hint using Xcode and I'm trying to make my
own custom framework which I can include from another application. So far, I've done the following:
Create a new project; an iPhone OS window based app.
Go to target info-> under packaging, change the wrapper extension from app to framework
Go to Action->new build phase -> copy headers. Change roles of headers to 'public'
From my application, I add the framework to the frameworks group.
Apple clearly said that you can not use dynamic libraries on their mobiles. And a private framework is just this.
You can, however, use static libraries.
Egil, that's usually considered as one of the implications of section 3.3.2 of the iPhone developer agreement, which (in part) forbids plug-in architectures or other frameworks. The fact that they don't provide an Xcode project template for an iPhone-compatible framework tends to reinforce the idea, though of course it could just be an oversight or something they're discouraging without actually forbidding.
Whether this is the intended meaning of that section is something you'd have to ask Apple about, and possibly consult a lawyer, but this is where the oft-stated "no frameworks" idea comes from.
For those who have framework code they'd like to use in an iPhone app, an alternative approach is to use the framework code to build a static library. That then gets compiled into the application instead of getting dynamically loaded at run time. The fact that it's part of the application executable avoids any potential concerns about this part of the agreement.
Though dynamic libraries are not allowed, you CAN create a framework (using static libraries and lipo).
Check out: http://accu.org/index.php/journals/1594
I haven't tried it for so called mobile device, but I would guess its very similar to the method for a regular Cocoa application. Check out this tutorial:
Embedded Cocoa Frameworks