I have an app written in MONOTOUCH. It works- I tested it with TESTFLIGHT. It is being added to a larger app, and that developer needs the full xcode project. Do I need to have it rewritten or is there a way to convert it easily.
There is no way to convert Mono code to Objective-C code.
There is an --xcode option that may or may not work. It has not been maintained and we do not officially support it, so I would not depend on it working.
My suggestion is to keep the two applications separate, and transfer control from one to the other by using urls. You register two url handlers "firstApp:" and "secondApp:" and when you need to go from the first to the second, you issue a Url open to "SecondApp:statevariables" and the same process is repeated to go back.
If you have a MonoTouch license, you can use mtouch --xcode yourapp.exe to generate Objective-C code. It doesn't work in the evaluation version.
Much more detail is available in this Stack Overflow answer.
Related
Can anyone suggest what to do about this message that I get when submitting my Xamarin Forms app to the iOS store?
Comment on possible duplicates
This question was asked before and not answered; I don't think an answered duplicate exists.
This is a known issue which was recently closed by the Xamarin team issue can be found here https://github.com/xamarin/Xamarin.Forms/issues/7323
And the fix is and i qoute
All the bits are in place, solution time! TL;DR: all is described in this piece of documentation here.
Make sure you are using the latest Visual Studio (for Mac) on the stable channel, that should put you on the right path. At the moment, you will need to use the Xamarin.Forms 4.5-pre1 preview release. I understand that this might not be an option for all of you, but rest assured, the stable package will be out well before the deadline. Stable 4.5 is planned mid to end of February.
Lastly, put the --optimize=experimental-xforms-product-type flag into your iOS additional mtouch arguments setting and you should get rid of the deprecation warning by Apple. If you don't have any references of your own to UIWebView of course 🙂
I would like to ask you to try this at your earliest convenience. Maybe not to release an actual new version to the store based on the Forms preview package, but at least upload a build to verify that this solution works correctly. Whenever you do, you can just update to the 4.5 stable package and release a new version with confidence.
If you do run into anything with this solution, please feel free to reach out to me directly (gerald.versluis [a with a long tail] microsoft.com) or open a new issue on the repository. Of course positive feedback is always appreciated as well 😉
I am using Xamarin and need to use a PCL
However, I cannot install ServiceStack into the PCL other than the PCL package which is classed as no longer being maintained
Has anyone come across this?
I want to use PCL because I dont want to duplicate code
PCLs are supposed to be supported via the latest Service Stack but this does not appear to be the case
I have code which makes use of ToJson which is in ServiceStack.TExt
I know I could create a folder inside my iphone (and android) assemblies but I am not sure this is a good approach because it doesnt feel right (everything all in one place instead of in proper layers)
Does anyone have any ideas about this?
Paul
Your assumptions aren't correct, ServiceStack PCL Packages ARE still being maintained, but instead of being maintained in individual packages, e.g:
ServiceStack.Client.Pcl
ServiceStack.Text.Pcl
ServiceStack.Interfaces.Pcl
They have now been merged as different profiles into the main client NuGet packages, e.g:
ServiceStack.Client
ServiceStack.Text
ServiceStack.Interfaces
I am going to upload my first mac app to Apple Store
And fixed all validation bugs of icon,category...
But after then I passed validation with warning :
The resulting API analysis file is too large. We were unable to validate your API usage prior to delivery. This is just an informational message.
And my upload be rejected with the reason : "Invalid binary"
Is there anyone has experience of this case ?
UPDATE : this warning is not the reason of rejecting, it maybe the app archiving problem. I successfully released my app to store.
So, we can safely ignore that.
Apple forbids using private or undocumented APIs in iOS apps. Any calls you make to methods that have the same name as private or undocumented API methods will be flagged as a private API use, even if the method being called is something you have defined yourself.
App Loader does an initial scan, checking for method names, instance variable access, and even #selector usage with private method names. App Loader doesn't always do a great job, and the more source files you have the more likely it is to give you the warning that the API analysis file it has generated is "too large".
Fortunately, you can still submit your application, despite of the warning. Apple will check it internally, and if something gets kicked back because of overlapping names, you'll have to wade through the review process again.
Erika Sadun tried to make an app called API Kit that would do the scanning for you, but she appears to have abandoned her work and removed any trace of the application from her website.
Chimp Studios created App Scanner to do the same thing, but it hasn't been updated since 2011. Unfortunately, for large projects -- and this includes projects with a lot of extra pods from CocoaPods -- there is no current (2014) good way of solving this problem other than proactively naming things such that they won't conflict with private API method and instance names.
You can proactively learn about Apple's Cocoa Naming Conventions and try to anticipate. That will reduce future headaches. Until Apple introduces something like namespaces, however, we may continue to run into this problem from time to time.
The "invalid binary" error can come from a number of causes, but it is entirely unrelated to the API analysis document created by App Loader.
You should know that even with the scanning, there are still ways to get around the prohibition on using private/undocumented APIs. :)
After hitting this issue for the first time on my first Swift project, it looks like the most common answer to this question is now:
If you use Swift 2.x and XCode 7, you'll get this error. Just ignore it.
[UPDATE: XCode 7.3 & iOS 9.3 rollout seems to have fixed this issue!]
Here is an easy way to get around them... store the selector name in reverse, like "dlroWolleH", then reverse the string before you call the method.
If Apple gets wise to that then you can encrypt them.
I'm discovering XCode and iOS development.
Delving into the iOS documentation, I've tried to download and run some of the programming examples.
As an example, I'll use AccelerometerGraph.
If I download the code and try to compile, i get an error message, and I realize that the Navigation panel tells me : Base SDK Missing.
After fiddling around (the existing answers on stackoverflow refer to the Xcode 3.2 answer, which doesn't work) I figured I should go to "Editor > Validate Settings…" and accept the changes.
It "seems" to work, (as in the "Missing SDK" message disappears, and I can compile) but I'm wondering if i'm missing something more fundamental.
Also, I thought if there is such a fundamental change, it would be useful to have it up there in one of the questions.
Thx
P.
Go to the project settings and choose "Latest SDK" for the SDK option and that should fix your projects.
And if you want to be super helpful, file a bug with Apple (at http://bugreporter.apple.com) and tell them to update these outdated sample projects to use the latest SDK's if possible.
Not missing something more fundamental. Apple's sample projects have a variety of vintages. Mostly they compile and link under the current versions of Xcode and friends. Some need to be brought up to date. What you found was one that was originally set up for an obsolete version of the SDK and it compiles and links fine with one that was automagically found on your system when you updated it.
I have custom frameworks in my app bundle for WebKit, WebCore, and JavaScriptCore. I would like all other frameworks that depend on the system versions of WebKit, WebCore, or JavaScriptCore to use my custom versions also. For instance my custom version of Webkit loads private system frameworks that in turn depend on the system version of WebKit. This means both my WebKit and the system WebKit get loaded, and usually a crash happens shortly after.
The way I understand this should be done, is to set the DYLD_FRAMEWORK_PATH environmental variable before your app bundle begins execution (Search order for loading frameworks can be found here: http://code.google.com/p/macdependency/wiki/SearchPaths). You can set environmental variables in code with setenv, but it won't take effect for the currently running process. I would have to re-launch the process again for it to take effect. I would like to avoid this too.
So my question is what is the best way to set the DYLD_FRAMEWORK_PATH before the execution of the my app bundle? This has to work in a release app bundle too. Is there a way to run a script whenever someone clicks on my app bundle before the executable starts running. Or is there any other suggestions out there?
Thanks in advance.
Jeff Wolski has the right idea by referring directly to Apple's documentation on the subject. This thread also provides excellent advice on how to get that going in Xcode, including corner cases associated with alternative methods of specification (for example, by using ~/.bash_profile directly for your user).
My reason for chiming in is you also asked for a script that might be able to assist you (and a bounty provider appears to have the same issue). It turns out Webkit references such a script in its documentation, which you might want to pick apart from the applicable Webkit source code. This should give you additional guidance on how, at least according to the developers, you should do this properly.
Best of luck with your project(s).
I would recommend environment.plist or the LSEnvironment key in the info.plist. Check out the link below.
https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html
WebKit currently has a script to do this for you, called run-webkit-app. See http://trac.webkit.org/browser/trunk/Tools/Scripts/run-webkit-app
Newer versions of ld understand the -dyld_env flag, which inserts a LC_DYLD_ENVIRONMENT load command into the binary (and as such applies essentially as early as possible in app execution). Perhaps adding -Wl,-dyld_env,DYLD_FRAMEWORK_PATH=/folder/encosing/WebKit/and/related/frameworks to your compiler flags might do what you want?