Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
Improve this question
It started one day while I was using my iPod Touch: wouldn't it be cool to have XXX function (from our internal desktop application) available on the iPhone as an native app.
I had that idea because (A) I think our current bulky desktop internal 6+ years old application suite needs a major face lift, and (B) instead of continuing our waterfall development methodology, which usually resulted in a project canned after tens of people spending months on something that no user cares about. I hope that we can start doing lots of tiny projects with 2 week iteration cycles using Agile methodology.
Oh, I also want to find an excuse to use XCode in the office.
After researching, I found out that pretty much NO COMPANY does iPhone native intranet applications because no company wants their internal development needs to be controlled by Apple who tends to kill cool apps like Google Talk. Since our company is ultra concerned about security and safety, the phrase "using a jailbroken iPhone/iPod Touch" is the same as saying "please fire me".
So I came up with plan B: using ComponentOne iPhone Studio to do a iPhone optimized intranet web application. I spent 2+ weeks and it is about finished. My supervisor seemed very excited about it, so hopefully we can turn it into a long term project.
My question is: have any of you tried writing an iPhone application (either native app or web based app) for your company's internal use, and what are the technical and political challenges?
I've written three internal applications (native) for my company.
We are able to use ad-hoc distribution (less than 100 users ; do not qualify for the 500 person enterprise program).
It's been great. The execs love it, our salespeople are using them like crazy. A few new customers have already been credited to being impressed by our tech and coming on board when they saw our apps.
Win-win-win so far.
We've talked about it some at my office, but that's as far as it's gone. The Enterprise developer license allows you to control the distribution of your app within your organization, not Apple. The AppStore isn't involved at all.
If you write your web applications well it is very easy to add an interface for most mobile devices not just iphone.
We use things like: intranet.domain.com/application/mobile/
We always create our web apps with layers of functionality so that the UI side is easily switchable. My favorite at the moment is MVC style. This way you just have a UI designer work on the mobile interface but all the underlying business logic is the same which ever device you are using.
I would also still love to write native iPhone apps for our systems as they are just much cooler :-) Damn you Apple for not allowing us.
I build all of my iPhone app as we apps using ASP.NET. ComponentOne has Studio for iPhone which lets you build ASP.NET sites that look and behave like native iPhone apps. It's a great solution for Microsoft developers like me who do not have access to Apple machine or Dev Kits.
I used it to build a mobile version of our website that calls the same class library our main website does. This is my favorite part of the concept, using my existing model.
Here is the link where you can read more about the iPhone ASP.NET controls
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I want to build an application for all platforms but I wonder!
What is the difference between ionic-Framework and Xamarin.Forms and,
Which is better to build an application for all platforms?
In the hands of skilled engineers, Ionic and Xamarin are both exceptional cross-platform development assets, which, compared with building native apps for two or more platforms, will save your business both time and money. Any decision about which one to use, though, should be subject to rigorous assessment of your needs, budget, and development objectives.
If app quality is a priority, you’re integrating with a lot of preexisting .NET architecture, and/or you need to build apps for a wide variety of platforms and versions, Xamarin will almost certainly be the best fit.
For smaller or less frequent projects on restricted budgets, Ionic will provide you with a fast and effective route to functional if unspectacular mobile apps for iOS and Android devices.
Depending on your resources, and whether you will develop apps in-house or with the help from external development companies, you might even wish to utilize both of these popular frameworks. Neither one is particularly costly to implement, especially since Microsoft started bundling Xamarin for free with the Visual Studio Community edition and Xamarin Studio (for Mac).
I think it mainly depends on what you want to do in your application.
If all you want to do is pushing some data and images (e.g. create a shop platform) i don't see any reason, why ionic wouldn't do the job and probably you'd see results a bit faster, as you don't need to struggle with a lot of native adaptions (such as file system access, etc...), though I don't think that choosing xamarin would set you back in terms of X months more.
However if it comes to using native features, such as camera, gps, sensors, whatever you will probably be limited to what the ionic api offers and I don't know how long the turnaround times will be until new features which may appear in the future are getting implemented into the framework.
Performancewise I am honestly sceptical if that mix of html, css and javascript/jquery will be anything comparable to what xamarin can get you to, as Xamarin actually produces an app which can compete with apps written natively.
I am not sure how deep you can get "under the hood" with ionic, though I know that with xamarin, you can actually go very deep and develop features that can use the native code of your target platform.
Actually by looking at the user base (or better to say the amount of questions here on stack overflow) one might be tempted that ionic has more questions than xamarin.forms, however that doesn't take into account that actually any question about xamarin, xamarin.forms, xamarin.android, xamarin.ios and c# might hold relevant answers and support for your upcoming problems. However to be fair, also ionic has quite an impressive amount of q&a answers posted here, so i would say that is a draw.
My conclusion would be: If you need to create a data-pushing app fast, you could use ionic, however if you need performance, native methods and want to be able to use particular native features, Xamarin would hold that door open for you.
Disclaimer: I have been developing apps with xamarin forms for about 5 years now and have never used the ionic framework at all and therefore my knowledge about ionic is limited to what I read on summaries. Probably my answer might omit particular benefits that ionic might offer and I really hope that a more experienced ionic developer might have something beneficial to add.
However, If you were asking about my personal advice, My answer would be: Use Xamarin
We had to answer this question about 18 months ago. For us the core question was if the app also needed to be deployed to a web environment. In our case we needed to support the same functionality in a native iOS/Android app, as well as a website (for the features that the web can handle). In that scenario Ionic is the clear winner.
If you don't have to worry about web, then I think Xamarin is a great option. I'd also be checking out Google's flutter too, which is a newer cross-platform option (again assuming no web needed).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I recently found in news that KaiOS has been used in 4G Volte Enabled feature mobile phones. I was wondering how to create apps for KaiOS. Any help on creating apps for KaiOS has been greatly appreciated.
You can find the kickstart here https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/Firefox_OS_apps/Building_apps_for_Firefox_OS but as KaiOS is B2G forked i would still suggest you to go to kaiOS official website to check the proper flow for the application development.
Below are the series of steps you need to go through if you don't want to get stuck in between of development:
First you should understand how applications actually work in kaiOS environment and for that you need to first understand the architecture for that. You can give a read to https://developer.kaiostech.com/introduction/architecture for more understanding.
Then comes setup for your application which you will find here at https://developer.kaiostech.com/environment-setup . Mozzila firefox shift+F8 will open the webIDE where you can see your devices connected but for that you should have proper drivers installed for your phone. You can use firefox emulator 2.2 (stable) as well for initial start.
Now its time to have your first application onboard to kaiOS . You can make your application in any of the client specific JS like angular , react or even plain javascript but the important part is to have manifest.webapp in root folder for compatibility.You can give a read to https://developer.kaiostech.com/first-app.
You are able to see your first application on your phone !! Now the real pain arrives when it comes to navigate through the application by keypad but thanks to naviboard library which will do this work for you to align your navigable items and navigate through it by simple API’s. You can find the library at https://github.com/amanboss9/naviboard.
When you are done with navigation part of feature phone, you can go through and develop as much as you can as if it is a web application and can develop a lot of things.
Check the sample project at https://github.com/amanboss9/kaios-angular-app. This Boilerplate can save lot of time when it comes to setting up everything from scratch.It included Angular1.6, naviboardJS(For auto handling navigation part of your application) and Gulp.
KaiOS is based on Mozilla's open source B2G OS. The apps are built purely with HTML/JS/CSS stack and any web application/website that is mobile friendly can be an app with just minor modifications. You can use the inbuilt webIDE to build apps for Mozilla OS, see more here.
https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/Firefox_OS_apps/Building_apps_for_Firefox_OS/Firefox_OS_app_beginners_tutorial
I used to build apps for Firefox OS before it was dead lets hope to see whether it's reincarnation succeeds.
I will try making apps when I get my hands on the Jio Phone and will update here.
Update:
KaiOS has released a newly updated their website with a new IDE called Kaiosrt which is much better and actually works.
KaiOS is a B2G OS forked from Firefox OS.
You can use Angular/React/Jquery or any JS lib/framework to develop apps on Kaios
Packaged app should have all js/image/html/css file packed locally, External link reference in index.html will not work. Blocked by default- CSP policy.
Mobiles (JioPhone/Nokia Banana phone) with keyboard needs to handle its own key events, Refer Kaios Sample app
This is in the FAQs of KaiOS offical website:
Can I develop apps for KaiOS?
KaiOS is a curated platform for apps and we are working closely with
app developers to provide the best experience for our users. At the
moment we are not accepting submissions into the Store, but will do so
in the future.
(https://www.kaiostech.com/faq/#question-12)
Guess you could leave your contact email there and will get updates in the near future.
KaiOS have officially launched the KaiOS Developer Portal.
It's got everything developers need to start building and distributing KaiOS apps.
Furthermore, build your first app with JavaScript (Vanilla), React,
Vue.js and Angular with code examples herein. Then, testing your
apps with WebIDE or Simulator.
Tools and resources include:
A guide to building your first app, with sample code, reference guides, and software development kits (SDKs).
Instructions for ENV setup to configure your development environment.
A simulator running Gaia and web apps in a Gecko-based environment.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Currently, I plan to port a Java desktop application, to the Android platform. Besides official Android SDK, I also take a look on, as it will be a plus, if it is able to run in iphone with minimal effort.
http://www.rhomobile.com/
http://www.phonegap.com/
appcelerator.com
Those cross platform frameworks seem nice. However, I was wondering, what are the limitation on those frameworks?
Will they still have the same look and feel as native Android application? (Or a native iPhone application)
Is there any difference in the speed and responsiveness of the application?
Are they able to provide same set of GUI components as in Android SDK? (Or iphone's)
Limitation access to I/O, network resource, hardware?
Ability to use threading?
From my experience (my background being native mobile app development), we get a lot more control with native apps vs framework based apps. That advantage has greatly reduced in android and iphone platforms, however there are a few other things to condsider:
If it is a one off app then you are
better off working with the
frameworks you mentioned, they
provide all the features you asked
about and for a beginner, are a bit
faster to develop.
If you are going to do multiple apps
then it makes sense to have a custom
framework for your needs. In this
case you can reuse parts of your
Java desktop app and absorb them
into your framework. You will
probably need to create iphone and
android/java versions.
If you create your own framework,
you can also incorporate other
software development best practices
like CI more easily when compared to
off the shelf frameworks.
The UI components are different for
Android and iphone and you are
better off having them different as
they have quite different
sensibilities and interaction. So it
may not be a good idea to aim for
one to one mapping.
Speed, performance etc are not an
issue, same for threads support.
Hope these points help in your decision making process.
This post will be immensely useful for you :)
Comparison between Corona, Phonegap, Titanium
As for threading - since both PhoneGap and Titanium (I cannot speak to RhoMobile) allow you to hook into native code from JavaScript (and the reverse) I see no reason why you cannot multi-thread an application using one of these technologies.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
MonoTouch seems like a great platform for iPhone development, but I'm concerned about deploying it to the Apple Store. Are there any examples of applications built with it that are currently available on iTunes?
We're starting a new project for the iPhone, and keeping the entire stack in C# would be great, but we don't want to incur the risk of being turned down from the Apple store because of MonoTouch.
I've read about several games that currently use mono (not MonoTouch) for 3D graphics, but couldn't find anything about MonoTouch.
Tapping this out on my phone, so going to be a little terse - apologies for that.
Anyway:
- As said in a previous answer, there have been MonoTouch apps released to the App Store. Whether it's two or a bajillion doesn't matter so much. The difference between one and zero is infinite - the answer is unequivocally: Yes, Apple will approve MonoTouch apps.
- MonoTouch plays by Apple's rules. It spits out native bits. There's no interpretation of code going on, nor is there any JITting. Your MonoTouch app is a bundle like any other, and it contains a native binary like any other.
- MonoTouch apps are larger than they would be if they were written with Apple's stack. This is because your MonoTouch app relies on a subset of the Mono/.Net framework. In that respect, though, once you get down to what ships, there's nothing especially different about a MonoTouch app. I worked at a company where we built our apps (developed with Apple's stack) against our custom framework. It increased the size of our apps, but it also cut way down on production time (and that's always the trade-off, right?). Plus, the size of the app bundle just after compilation can be deceptive. Because bundles are zipped for the App Store, the size decreases dramatically - you can easily write a MonoTouch app that falls well within the acceptable size limit for apps delivered OTA (I bring this up because it's a question MT n0obs (rightly) tend to ask). So, Apple doesn't have any real reason to reject based on size.
- Whether it's MonoTouch or a custom in-house framework like the one I used to work on/with, the MonoTouch stuff, when shipped with your app, is just another framework that could've been written in Objective-C.
- If you're concerned about configuring your app for distribution using the entire MonoTouch stack and how that might affect your chances of approval, you can tell MonoDevelop (or the mtouch utility from the command-line) to output an Xcode project. You'll see that your code has been transformed - you'll be looking at native assembly (not some flavor of an IL). You can build and run your MonoTouch produced app from right within Xcode, by which time MonoTouch is basically out of the picture (except as a framework you're building against (like MapKit, for example)).
For some reason, all of this bothers a very small, but vocal, subset of iPhone devs who, for whatever reason, can't stand the idea of people they don't know using a different tool to build apps. But their hateage doesn't change the simple fact that Apple has accepted MonoTouch apps (and Unity apps long before that).
The biggest reason you're going to see for MT apps being rejected is that MT devs, in my experience (I've been talking to quite a few - after giving some talks, posting to forums, mailing lists, here...), is they they haven't yet learned how to develop an iPhone app. That's something iPhone devs must do regarldess of how they write their apps. MonoTouch isn't the obstacle - it's knowing, for example, that Apple wants your app to look a certain way and to work in a certain way - it should look and feel and behave like other (good) iPhone apps, and shouldn't be among the examples of attempts to write desktop apps for a phone (which is where your average dev makes his first mistake when transitioning to mobile development).
Ultimately, your tool of choice isn't going to matter as long as it creates bits that play by Apple's rules (like MonoTouch). The real obstacle is learning the iPhone Way of app design.
.Net application devs, whether on Windows, Windows Mobile, or wherever Mono (not MonoTouch) runs, are accustomed to developing apps according to their own tastes. That doesn't fly in the iPhone world.
You can safely go with MonoTouch. As has been shown, Apple will approve MT apps.
The thing you really need to do (again, regardless of which dev stack you choose) is read Apple's docs on iPhone app design and their guidelines. There's a huge crowd of devs out their attributing their app rejections to Apple being evil (or whatever - uninformed excuses, basically), when the truth is that their apps are garbage and it's clear the devs didn't play by the rules (or even bother to read the rules).
In the end, in many cases, you'll write far less code when using MonoTouch, and the cost for that is a larger app bundle (which, as I said, will come out very reasonably sized after it's been zipped for distribution).
That's not much of an issue. With 3g, users don't sweat downloading 2-3MB sized apps. If it's small enough to send OTA, everything's fine. And in cases where your app goes over the limit, it's likely embedded resources (media - images, videos, etc. - that's how bundles typically swell to wifi-only sizes), and that's something Objective-C devs have to deal with, too, so that's not a MonoTouch problem.
So, ignore the haters (who haven't even tried MonoTouch or bothered to learn how it works), and rest assured that, as long as your app conforms to Apple's guidelines, there's no reason for them to reject it. It doesn't mean your app is guaranteed acceptance as long as you design it correctly (plenty of apps get rejected for no apparent reason), but you can consider yourself, more or less, to be on equal footing with devs using Apple's tools.
Hope this helps :)
The MonoTouch community is maintaining a list of MonoTouch applications that are available today on the Apple Store and that have been written using MonoTouch.
The unity game developement platform is using the same mono touch code base for C# support (and have contributed to the project).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Given the landscape in which mobile applications exist is currently changing, i expect the "best" answer to this question to change as well, but for right now, which are the best operating systems/frameworks upon which to build mobile apps today.
I'm thinking in terms of cost, learning curve and market penetration.
Android
Cost: 0
Learning curve: More or less 0 if you know Java
Market penetration: HUGE
Android phone sales is expected to rise 900% this year, and the market isn't limited to phones. Some mini computers are going in that direction as well, choosing Android as their OS.
You need to define the end-result requirements for the application.
Part of the answer depends on what mobile hardware you will be running. And, whether or not you need to use unique abilities of your hardware (touch-screen, barcode scanner, gps, special buttons, VOIP, etc.) or if a simple input/output screen framework is sufficient.
That might drive your decision towards a local application or something more remote like a web application or terminal services. (There are, of course, local applications that use remote services also. Do you need to consider multiple front-ends?)
In addition, where are your development strengths? What are your language proficiencies? As you mentioned, mobile application development can have a steep startup curve for learning and for setting up your initial development/debugging/deployment environment. Is that worth it, or can you leverage desktop or web development experience and deploy remotely?
Once you make these decisions and determine your development environment and target, then you can take the next step to look at frameworks and methodologies specific to your needs.
This just in -
Today's Code Project Insider included this InfoWorld article -
"How to choose a mobile
development platform"
In terms of market share, at this point you won't get better visibility and hit ratio than you will get with the iPhone. There are plenty more Blackberrys than iPhones, but the number of people who buy and download apps on the iPhone are much much higher.
However, the cost are pretty high if you want to start developing for the iPhone.
You have to get a Mac if you want to do any sort of iPhone development. That'll set you back at the ~1k on the low end.
You'll have to pay for the iPhone Developer account for $99/year
Learning the iPhone SDK, which is in Objective-C, will be similar to C/C++ if you already know it.
That said, who knows what kind of splash the Palm Pre will make. So market share will be unknown, and I'm not sure of cost, but if you know HTML/Javascript, you're set.
In terms of Android, while it's a nice platform, market share is still barely a drop in the bucket. It is written in Java, and it has a lot of nice APIs, but until you have a lot more people with Android devices in their hands, it's kind of moot.
Blackberry would be a good platform to develop on if not for the iPhone. The SDK is in Java and from what I hear have decent tools to get the job done. The advantage here is that you'll have a lot of potential for consumer facing apps and potential for enterprise apps (because every business has too many of these :)
So, it depends on how much you want to spend and what kind of apps you're going with. Learning curve, I think, shouldn't be an issue because each of these platforms has their own SDK you'll have to learn anyway, so you're starting at about the same level for each of these platforms.
My picks are (in order):
iPhone
Blackberry
??
That said, that is the current view of mobile app development. It's always good to keep updated and at least have a notion of the other platforms so you could potentially branch out.
As you wrote, the environment is constantly changing, but if you plan to make your app the most portable as possible, in my humble oppinion you need to start developing with Java Micro Edition (J2ME). One of the best IDEs for the job is Netbeans.
Depends on the device I suppose. I don't think there is one common way to write something that will work on every device.
The big ones would be:
Windows Mobile: C++ or .NET Compact Framework (JavaME if you install the Java Runtime manually)
iPhone: C++ (i think). IIRC it doesnt support Java yet.
Android: JavaME
Blackberry: JavaME
Other non-smart/PDA devices: Probably C++?