As Apple allowed IDE-like application in AppStore, there are some apps like Continuous, CppCode, Pythonista, even Apple's official Swift Playgrounds, letting users typing in source code, compiling and running them locally. I did a few tries but it seems system() call is still forbidden in the latest iOS SDK (version 11.2), and NSTask is also not available. So how does the above IDEs run the compiler and the compiled executable? And quick examples?
Related
Recently my app was getting crashed on IOS8 because i have used an API which is only available for IOS 9 and above. I am wondering is there anyway to check the whole project and find out if I am using any API which is not available for the current development target. Something like the warnings for the deprecated APIs. Thanks.
In order to tell the compiler you want to support an earlier OS, you need to set the SDK to that earlier OS's SDK. If you set the SDK to iOS 8, then any time you use functionality from a later OS, you should get a compiler error.
I create some business application on Appcelerator Studio(sdk version:6.1.0.v20161230103702).
It run iOS simulator(iPhone 7(OS 10.2)),
so sometimes popup "App May Slow Down Your iPhone.." alert.
I wanna prevent this alert.
would appreciate any comments or suggestions.
You might want to take a look at this SO Q&A, this other Q&A, and this third one. There could be something there that you could adapt to Appcelerator Studio.
This alert is supposedly shown for apps developed for the 32 bit architecture.
read here
I wonder though how the ti sdk 6.1.0 would get you this issue.
what Xcode are using ?
Update :
Where did you get that sdk version ?
For production, use one of the GA titanium sdk versions, the latest one (as of the moment of writing this) is at 6.0.2.GA
To install Ti SDKs use this command
appc ti install sdk 6.0.2.GA
If you don't have an appcelerator indie account, you can use this node package tisdk to install new titanium sdk GA releases.
You might be using the latest SDK with the compatible XCode, but are you using any external modules which may not be 64-bit comptible. Can you remove any additional modules, and see if you are getting the error or not. If not, then you need to recompile the modules with the latest SDK or atleast a minimum of 3.5.0.GA from which the 64-bit support was provided.
My company integrates Unity games into our native iOS app. Basically our iOS app would run the Unity code when a user decides to launch any of the games.
With the past 32 bit of Unity and native iOS code, we were taking Unity generated Xcode files, and compiling it into a static lib for the native iOS app to use. Whenever the user chooses to launch any of the games, UnityAppController would be loaded, and ran. This worked well for us.
But with the latest 64 bit builds, the same approach would give us a runtime error on app start - specifically when "main.mm" is executed, the app would crash at the "InitializeScriptingBackend()" call in "main.mm". Please see attached screenshot for sample stack trace.
Same issue happens regardless if we are running in debug or release scheme.
We are currently using Unity version 4.6.3p3 for generating the games for iOS, and using Xcode 6.2 for compiling the Unity code to static lib.
Does anyone have any idea why the crash is happening, and how we might get around it? Thanks!
Another discussion is happening on official Unity forum: http://forum.unity3d.com/threads/runtime-issue-with-64bit-unity-game-integration-into-ios-native-app.316796/
I have an application where I am supporting a deployment target of 4.3 with a base SDK of 6.x.
I find myself having to weak link API methods and provide alternative workarounds for older runtime based on strategies found in the document "Using SDK-Based Development".
The problem I am facing is, occasionally and unintentionally, I would use a method that is available only in a newer SDK without realizing it and did not weak-link the method. This causes a crash for users running the app on an older version of the OS.
While I know the number of users having that old a runtime (iOS 4.3) is diminishing, I would like to know if there is a tool or a way for us to generate a report that would list APIs available in SDKs other than that of the deployment target, so that I may review the code to ensure proper weak-linking is performed, prior to shipping the product.
Off the top of my head, compiling the source to an older version of the SDK should throw errors, but then again, Apple's strategy has always been to ship new XCode without older SDKs.
I am not looking for a perfect solution. Any other workarounds would be helpful too.
If you don't mind paying, Deploymate can scan your project and identify API calls which may fail on older operating system versions. Works with Mac and iOS apps/projects.
Deploymate helps you identify unavailable, deprecated and obsolete API usage in your Xcode projects
I don't have a Mac, but I have an iPhone. I want to develop applications for iPhone.
After some research I think I need just the headers and library from the free SDK, and a GCC build that supports ARM/Mach-O.
Apple released the code for GCC used in the iPhone SDK (they had to), So I think if I could build it on Windows or Linux, I can use it with the headers and libs from the SDK to develop iPhone apps.
I can then install the app on any Jailbroken iPhone.
How to build it on any non Apple machine?
Look into winchain - this tool builds the iphone chain on windows allowing you to compile iphone apps on windows:
http://code.google.com/p/winchain/wiki/HowToUse
-Adam
Check iOS Build Environment for Windows. From what I see it uses llvm compiler and is frequently updated. You can use it with your own editor or use a stand alone wizard to generate a Visual Studio project (works with both VC++ and VC++ express). The only disadvantage is that it has a demo version and requires donation for full version. However I expect you would be able to use the toolchain included in the demo without a problem.
I've downloaded the demo and played along with my own project and samples provided. It compiles just fine. Unfortunately I'm unable to test the results on my devices since none of them is currently jailbroken.