Limitations of iOS apps designed with Flex SDK compared to XCode - ios

I need to make a decision as to whether I develop apps for iOS using Flex SDK or XCode. Are there any limitations to date when it comes to developing apps for iOS with Flex SDK compared to XCode?

Yes, there are numerous limitations for developing iOS apps with the Flex SDK.
Some examples:
You don't get access to application didFinishLaunchingWithOptions
You can't change the device volume with actionscript
You can't get network status (3G vs. wifi, airplane mode) via actionscript.
Native Extensions let you bypass some of these restrictions, but that complicates your project.

Related

Can I migrate a Flutter app to a native iOS app?

Myself and a team are starting a potential startup and one of the things we want to do is a mobile app. We have already identified the target audience to mainly be iPhone users. But here in the US there's still plenty of Android user so we've been considering using a cross platform framework like Flutter. I've seen a lot of praise that Flutter is easy to use and can help us deliver an MVP faster. My ideal situation is to start developing with Flutter and when the app is successful migrate it to a native iOS app using Swift. But is that possible at all? Or if we decide to go native when we already have a flutter app, do we need to start from scratch?
Developing a Flutter app is completely different from developing an Android or iOS app. It has different language, has it's own architechture with it's own packages/dependencies/plugins.
You cannot convert from one of them to the other.

Is it possible to convert angularjs web application to IOS app with Ibeacon search functionality?

I have developed a web application using angularjs, now i want to convert ios application with iBeacons device searching functionality.
Is it possible to do this, any one please give me advice on this?
Yes this is possible, you can repurpose your Angular single page app into a Cordova/PhoneGap container, then use appropriate plugins (which bridge platform specific native code to Javascript) to add iBeacon or other beacon support. If you don't find plugins that do what you want, you can create your own if you are comfortable working in the native languages of the platforms you want to use (Java for Android, Objective C or Swift for iOS).
Example plugins that already exist to help with this would be:
cordova-plugin-ibeacon
ngCordova Cordova Beacon
There's an example of how to go about this using Angular JS / Ionic framework here.
There is no way to directly scan for beacons in JavaScript. This is true whether you are talking about a web app running in Mobile Safari on iOS or inside a UIWebView container within a native iOS Web app.
If you want to combine JavaScript-based apps with beacons, the alternative is to build Hybrid apps using technologies like Cordova or Ionic (which is built off of Cordova). You can then use Cordova plugins that let you interact with native code that does the beacon scanning, and pass it back to your JavaScript application. One such plugin that accomplishes this is here:
https://github.com/petermetz/cordova-plugin-ibeacon
There are limitations with this approach. Beacon scanning typically has to be in the foreground, and you can't really wake up the app on beacon detection.
Full disclosure: I am the lead developer on the Android Beacon Library open source project upon which the above plugin is based.

Does webRtc Hybrid app run on IOS

I want to develop IOS application using sdk like rtc.io I want to know whether javascript based hybrid application will run on IOS or not? Is there any available free SDK for IOS native webRTC Data channel app development?
yes there is a recent release of opensource webRTC supported browser by Ericsson laboratories, its cross platform and the first browser with webRTC support.
http://www.ericsson.com/news/1860225

Using twilio sdk for an iOS app?

I am planing to develop an VoIP iOS app and use Twilios SDK. I am making the choice to either use LiveCode, Appery.io, PhoneGap or build a native Objective C app. I am going to build the app for iOS, Android and HTML5 so the ideal would be to develope in JavaScript for all platforms, but as I understand the support for WebRTC is laking on the iPhone so the alternative for iOS is the native twilio SDK.
My requirements is:
be possilbe to use in iPhone 5 with iOS 7 be able to use twilio iOS
SDK´s voip functionality or twilio´s js SDK (if it is possible to
wrap a browser that supports RTC in the code?) be able to integrate
billing such as in-app payment or paypal with zooz or similar
communicate with REST API´s such as Amazon S3 or a node.js server
store temporary info in a SQLLite db when app is off line make fast
and responsive views (file listings etc) is very important
create cfuuid´s
I have seen several Twilio projects that use PhoneGap but none that are using LiveCode.
I have already built an iOS VoIP app in Objective C, but I want to be able to release it on several platforms also such as for Android and build a HTML5 app, without redoing everything.
This isn't really a programming question and should perhaps not be asked here.
You can create an external for LiveCode and quickly create an interface using the LiveCode IDE. This is probably a quick and easy way to make a working app. If you're starting with LiveCode but are experienced in Objective-C, creating an external won't be a problem for you.
LiveCode doesn't contain native iOS controls, which means that you have to emulate the GUI. If you use PhoneGap, you also will need to compile a plugin for PhoneGap using Objective-C, but you can use a framework, such as JQuery, to get the right GUI.
Either way, you will have to compile the SDK and you'll need to be quite profound in Objective-C.
LiveCode will meet all your requirements. However, Apple will deny your app if you use PayPal for in-app purchases. You'll have to use Apple's in-app purchasing feature. I believe this is possible in LiveCode now. I'm not sure how easy it is.
I'm not sure about file listings either. On iOS, you won't have complete access to all files on the phone. This isn't a LiveCode limation but a limitation of the OS.

How many versions of Blackberry apps we have to make?

There are basically two issues that are confusing us:
Will a Blackberry app made for mobile phones work on the Blackberry tablet? I see that there is a tablet SDK as well.
Do we have to make a separate versions of Blackberry app for different mobile phones?
The reason we ask this is because we come from the Android environment where we can use one SDK to make app which will work on all mobile phones and tablets as well.
The BlackBerry Smartphone SDK is different from the BlackBerry PlayBook Tablet SDK.
The smartphone applications are written in Java (RIM's version of J2ME, essentially), while for now, there are two editions of the PlayBook Tablet SDK: WebWorks, for development with web technologies like Javascript, HTML, and CSS, and one that is Adobe Flash/Actionscript/Air based. I think there is also one in development with C++ as a foundation.
You can start with the BlackBerry Developer zone - it covers development for both smartphones and tablets:
http://us.blackberry.com/developers/
The BlackBerry Tablet SDK for Adobe AIR can be found here: http://us.blackberry.com/developers/tablet/adobe.jsp
The BlackBerry Tablet WebWorks SDK can be found here: http://us.blackberry.com/developers/tablet/webworks.jsp
Information about development for the BlackBerry smartphones can be found here: http://us.blackberry.com/developers/javaappdev/
For smartphone development, you would probably want to target the minimum RIM OS that would include the most devices owned by your target customer base.
Right now, RIM claims that more than 96% of BlackBerry smartphones can be reached using SDK 4.5 or higher.
RIM keeps an up-to-date set of statistics on this: http://us.blackberry.com/developers/choosingtargetos.jsp
Typically, if you're targeting recent devices (4.7 and newer), then you don't need to worry about splitting your code to target multiple devices, as long as the UI is written without making any assumptions as to screen size, etc.
If you're targeting anything older than 4.7, then it may benefit you to make two versions - one for touch screen devices, and one for devices that aren't touch-screen. The touch-screen API is introduced in 4.7, and while it's somewhat backward compatible, in our experience, while you need the touch-screen API available for devices that support it, it's best to leave it out for older devices that do not have support for the touch API or the virtual keyboards that come with it.
If you're going to split the code, RIM's compiler does come with a C/C++ - style preprocessor which comes in very useful.

Resources