I am bidding on a project where the client wants the mobile app delivered in an XCode project as that they can sign it.
Can I build in MonoTouch, then "Export" to Xcode so that I can deliver that to the client?
My experience is that I can build in MonoTouch in roughly 1/2 the time as I can in Xcode. Mostly due to MonoTouch.Dialog and C#'s framework sugar.
I am using MonoTouch Enterprise 5 and MonoDevelop 2.8
I think a lot depend on the definition of "export to Xcode" and I encourage you to clarify this with your client.
If the technical requirement is simply to sign the application the know that the code signing step, done with MonoDevelop (or with the mtouch command-line tool), is simply calling the codesign tool which is provided by Apple. That step is applied on a fully built .app (directory) so anyone should be able (with the right certificates/keys) to sign it (as long as the .plist data match).
There is also some support to (in mtouch) to build an Xcode project (see --xcode option) that could prove useful. This is something you can (and should) try to ensure it can as is match your (client) requirements.
Finally there could be ways to create a dumb Xcode projects that could be used only to copy and sign files. I'm pretty sure that would be possible with VS.NET/msbuild and MonoDevelop/makefiles - but I don't know Xcode well enough to say if that's a possibility.
Conclusion: the only thing I really don't doubt is that you can make this with MonoTouch[.Dialog]/C# in half the time than other solutions ;-)
Related
I have the same problem with Xcode Cannot Run on the Selected Destination
The destination does not support the architecture for which the
selected software is built. Switch to a destination that supports that
architecture in order to run the selected software.
I tried the solutions there and it doesn't work.
So I'll try to do something more reasonable.
What does the error means anyway? What is Xcode trying to say when it says to switch to a destination that supports that architecture? Where is the archtecture specified? What software? What is the problem?
While solutions may be nice what I am looking for is understanding of what it really means.
The project used to work
The project still work in real iPhone but not simulator
I used the newest facebook SDK. However, it run before even after the SDK. It's after I clean project it doesn't work.
While I don't have a solution for your problem, I can answer your question, namely, what does Xcode thinks is wrong and what does the error means.
So, the destination is actually your simulator in this case (could be the iPhone as well, if you're building for it). The architecture is decently explained here. What you need to understand is that in order for a software to run on a specific architecture it needs to be build for it(or assembled for it, to be more precise). That means that for the same software the CPU instructions are not the same for an iPhone (which has an ARM CPU) as they are for your iMac (which is x64).
Now, with the above in mind, what Xcode is trying to say is that you are trying to build the wrong architecture for your simulator and you should switch to a different destination that supports that architecture (as you mentioned, you can build just fine on the iPhone, which is a different architecture) in order for the software to run.
It could be an Xcode bug or a misconfiguration. You're probably better off creating a new project and copy all your classes into it than hunting it down.
You'll be happy to know this problem has a very simple solution. Select Info.plist in your project navigator tree and make sure it is not assigned to a target. I have confirmed this is the correct solution. If building for iOS 6 or earlier you may also need to add armv6 to supported architectures
I'm a developer, with years of experience in C# as well as Java.
I have developed a few ADT projects for my Nexus One Android 2.23 phone.
I am considering further mobile development and I heard of Mono for Android/iOS and Xamarin. At first I thought Mono would recode to Java, but now I understand that it compiles to native C code and runs over mono libs.
So I was wondering how much bloat does this add to apps, as I believe size of download is directly linked to number of downloads (I myself sometimes don't download something due to it being > 1MB)
If there is someone here who uses Mono I would love to hear from your experiences.
I understand there is a Visual Studio 2010 Plugin for Mono. Do you recommend it?
So I was wondering how much bloat does this add to apps, as I believe size of download is directly linked to number of downloads (I myself sometimes don't download something due to it being >1MB .... )
Monodroid apps are usually somewhat around 5 Megabytes (if Linked) because the runtime is embedded in the app.
If there is someone here who uses Mono I would love to hear from your experiences.
All in all i'm pretty happy with Monodroid. Java tutorials on Android are easy to translate or if too big you can create Bindings. I've only done one project on Mono so my experiences are limited but thus far i've expected nothing that would make me regret my choice. On the other hand, if you're familiar with Java (and like coding in Java) their is no reason to switch over except for Cross Plattform apps (see Monocross).
The VisualStudio plugin is necessary to develop in VisualStudio. The new version comes with a Layout Designer like the Android Eclipse plugin. I'd recommend you download the trail version from Xamarin and try it (the trail has no expiration date, it lets you only deploy to an emulator)
Apple has killed Carbon for 64 bit applications. I've got a pile of legacy code that targets carbon UI widgets that I'd like to keep alive for a while. Most of it is in the form of plugins and bundles that will have to go 64-bit in sync with their host platform.
The choice that Apple seems to be assuming is to throw all the legacy code away
and rewrite using Cocoa. It's not going to happen in the short run, if only because
the same legacy code is tied to a PC binding as well.
I'm considering 3 Options
(1) Dive into cocoa, create a compatibility package that supports the small subset
of carbon that I actually need.
(2) use Cocoatron as the new target. In the short run bridge carbon-to-cocotron, and maybe in the longer run convert to cocoatron native for both mac and pc. (ref: http://cocotron.org/)
(3) use QT as the new target. See option (2). (ref: http://qt.nokia.com/)
What I would really prefer is a fourth option, such as a bootleg copy of the 64 bit
Carbon beta that Apple killed, or a compatibility package explicitly intended just
to emulate carbon.
I would recommend you choose option 1. Creating a Cocoa UI wrapper for your code will likely not be as complex as you think. A common way to create a cross-platform app is to create the bulk of the app in cross-platform C++ and use Cocoa/Objective-C++ for the Mac UI and one of the Windows APIs for the Windows UI.
This option also has the advantage that it is fully supported by Apple and the APIs are stable and mature.
Cocotron is a nice idea but as of now it's not mature enough (in my opinion) to provide a robust cross-platform solution. I know there are successes with it but the sample size is small.
Qt is an option. However, it suffers from a very un-Mac-like UI. Using a Qt app on the Mac always feels like a quick port rather than a native app, and this is unlikely to ever change.
The "bootleg Carbon runtime" is just a fantasy, there is simply no way to get that working reliably and absolutely no chance to distribute it. You will need to find another way.
In iOS5 Apple drops the armv6 architecture from the ARCHS_STANDARD_32_BIT.
In order to keep the support for iPhone3G I still want to compile in armv6 even in iOS5.
Did anyone find a solution for this?
I just built something today specifying a deployment target of iOS 4.0. With only armv7 specified in Architectures, Xcode warned me that to support anything below iOS4.2 I had to include armv6 in Architectures. Just edit that field, click the "+" button when the dialog pops up and enter the literal "armv6".
In my case, we want our app to work under iOS4 and iOS5. We had to make some modifications so it would work correctly under iOS5, but all those changes were done with iOS4-friendly code changes.
We also added some iOS5-specific capabilities in a manner that allows the app to run without crashing under iOS4. Specifically, we tested for iOS5 capabilities before trying to use them, and linked iOS5-only libraries as Optional.
So, supporting iPhone3G in an iOS5 world could just as easily mean "we want our app to run on iOS4 and above (regardless of any iOS5 feature use)" rather than "we want to make sure our app runs on an older device running iOS5". There's a difference here; think about it. :-)
Anyway, adding armv6 support back in is very easy. And I guess the point is this: At some point, when there are no more armv6 devices out there to worry about (for whatever reason) you won't have to build for it. Apple's view is everyone should upgrade to the latest hardware as soon as possible. So in that world, there is no need for the tools to default to anything but the latest and greatest too. :-) Fortunately (or not), we developers live in the real world and recognize that you have to support older stuff for a while. And I guess the Xcode dev team knows this too, which is why you can add armv6 support back in quite simply.
The simple answer is that you have to change the current settings from "Standard (armv7) - $(ARCHS_STANDARD_32_BIT)" to just be "armv6" and "armv7". See the image below. You have to delete the line with the previous settings for it to work.
also make sure you set this in Project AND Targets ... cost me an hour to figure that out. had set it for one but not the other. hope this helps. GLTA
I think there's a reason why Apple dropped armv6 from the standard setting.
I have compiled armv7/armv6 with iOS5 SDK, however, the armv6 compiler produced wrong code in release mode. After hours of finding a workaround (trying llvm or gcc with different optimization levels) I give up.
So, I am going back to iOS SDK 4.x as long as I support older armv6 devices.
Example of code:
// myView center=(160, 100)
CGPoint p=myView.center;
// now p=(100,100) (what the heck?)
p.x=myView.center.x;
p.y=myView.center.y;
// now p=(160,100)
p.y+=100;
// now p =(200,200) (what the heck?)
Maybe I'm have some memory corruption, however, on the armv7 compiler and on iOSSDK < 5.0 it behaves as expected.
Best regards
Not sure if this is actually a solution yet, but I have discovered that replacing the defined string in "architectures", which was $(ARCHS_STANDARD_32_BIT), with "armv6 armv7" allowed me to compile with iOS5 as a base and iOS4 as a deployment target, and pass validation .
I am not using any IOS5-exclusive libraries or calls, but intend to in my next release.
I did not need to replace $(ARCHS_STANDARD_32_BIT) with just armv7 for the app to compile and be uploaded to the App Store.
As suggested by MarkGranoff, I simply added armv6 as plain text, by hitting plus and just typing it in on line two.
I am trying to find memory leaks from my Xcode project. I don't know, what happened - I can't select anything from Run->Run with performance tool - the list of things are disabled.
Please help me, I am a beginner.
The problem was i have deleted the build folder and was trying to run with performance tool, without building the code again, if you need to test your app with performance tool, you must compiled your code, and you need to have build folder in your project.
I believe you are building an iOS program. As said by Apple engineers, most items under Run with Performance Tool need dTrace support, but dTrace is not available for iOS yet, not even for simulators.