Why is using MonoTouch for iPhone development not recommended? [closed] - ios

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We want to develop an application for iOS and Android smartphones. We are mainly using Microsoft technologies for developing our applications. We thought that if we would use MonoTouch and Mono for Android we would only have to maintain one code base with only a different UI layer for each device.
Because currently nobody in our small team ever developed a smartphone application and we need it quickly we want to outsource it. We asked other companies whether they perfer MonoTouch or Objective C for iPhone development. Most of them said, that the would choose Objective C. They said that Objective C offers more functionality and possibilities, it's faster and for MonoTouch there is a chance that Apple will not support it anymore in the future. Is all of that true or are there other reasons to prefer Objective C? I know there are other threads like this around, but they did not answer my questions, especially the one regarding Apple's support for MonoTouch.

applications. We thought that if we would use MonoTouch and Mono for
Android we would only have to maintain one code base with only a
different UI layer for each device.
this is a possibility IF you structure your app right. If not: no.
If you use Java+ObjC+C# (for WP7 / Win8 metro etc) then this is not an option AT ALL
Because currently nobody in our
small team ever developed a smartphone application and we need it
quickly we want to outsource it. We asked other companies whether they
perfer MonoTouch or Objective C for iPhone development. Most of them
said, that the would choose Objective C.
If you are outsourcing it, you should dictate what you want it written in, surely? If you need to support it in-house, and you only have C# skills, then MonoTouch etc makes more sense for you, the people paying the bills!
They said that Objective C
offers more functionality and possibilities,
FUD, and also incorrect. Monotouch has the full API available. If it's not there, as Xamarin to bind it (which they have done often before)
it's faster
I'd love to see the benchmark. Yes, technically, it can be faster in some circumstances, but in general use, MonoTouch the same or quicker.
Programmer error is a more common cause of iOS app performance problems. eg not getting things off the UI thread (which is easier to do in MonoTouch than in ObjC, tho blocks have helped that a lot), or taking too long to get out of FinishedLaunching (the "main" method, if you will, tho it's not really...)
Garbage collection and things like linq, xml/json parsing, generics and collections are also hugely valuable, and very quick.
and for
MonoTouch there is a chance that Apple will not support it anymore in
the future.
yes, there is a chance. There is also a chance that Tim Cook will run off with Apple's billions and buy all of Hawaii (rather than Larry Ellison's "I'll just have this island" purchase). But the chances are now rather slim.
Is all of that true or are there other reasons to prefer
Objective C? I know there are other threads like this around, but they
did not answer my questions, especially the one regarding Apple's
support for MonoTouch.
Apple doesn't support MonoTouch. Xamarin does, and they do it exceptionally well. Apple doesn't support anything except XCode, which is their product.
Apple DOES allow MonoTouch apps (there are lots). Another way to look at it: usually, 95% of the top 100 games are written using Unity3D, which is based on the same techniques (ahead-of-time compilation of C# code and embedding a cutdown version of the Mono/.NET framework).
There ARE reasons to prefer ObjC which would be:
You already know ObjC and CocoaTouch and like it.
Your team already knows ObjC and CocoaTouch or you can easily hire people who do (note: currently, as far as I know, iOS developers are CRAZY expensive to hire, if you can get them)
You need to use the beta's the day they come out. Keep in mind that you can use the current MonoTouch and deploy to your iOS[REDACTED] device with the beta on it. You just can't use the new stuff in iOS6 YET (Xamarin said "around 2 weeks" which should be about now...). Also keep in mind that you can not deploy an app to the store which is built with the beta SDK, even if you don't use any of the stuff in it. You can't even mention iOS[REDACTED] in your product description (I've tried)
you love [squareBrackets andTheOccasional:#"strange syntax things"];
Now, will building a cross platform, shared code app be an easy undertaking? HELL NO. It's a very complex piece of development for a non-trivial application. But thats the fun part of software development: if it was easy, it'd be boring! Grab Greg Shackles book ( http://www.amazon.com/dp/1449320236 ) to get an idea of whats needed for iOS+WinPhone+Android style development.

My hunch is that the companies you talked to simply are used to using Objective-C. That's where their skills lie, and that's the biggest reason why they would prefer not to deviate from their path. The other reasons can be argued both ways.
It's true that no one can predict what Apple will do, but there's a very small likelihood that Apple will ban third-party toolkits & APIs like they did in the summer of 2010. That was only a short period of time, and they completely reversed that decision. Their current focus is on making app development easier, which means keeping the field open to alternative development methods. I think MonoTouch is safe.
As for speed, C# generally produces very fast executables. They may not be quite as fast as Objective-C, but I doubt you'd notice a difference. I remember seeing a website somewhere that showed C# outperforming C/C++ in some tests, but that was in the .NET environment, not Mono... and unfortunately I can't find the reference anymore. I'll keep looking. But the bottom line on speed is that C# speeds are very good. It's not like BASIC vs C. More like Java/JIT vs C.
C# gives you many, many(!) advantages over Objective-C, and they have been enumerated in other Stack Overflow answers, so I won't repeat them here. You can find them easily enough.
I'm an obvious fan of MonoTouch, but I do have to say one thing: I think it's a mistake for companies to think that because they are fluent in C#/.NET that they will easily be able to develop and/or maintain iOS apps using MonoTouch. It's just not true, because MonoTouch is basically a C# layer over the CocoaTouch API, meaning that you have to learn the Apple way of doing things. You have app delegates and view controllers and all the UIKit stuff. There's a real learning curve there. But if you're fluent in C#, MonoTouch will be a huge help.
UPDATE:
I found the article on C# speed: Head-to-head benchmark: C++ vs .NET

I have actually used MonoTouch for every app I've ever developed. Performance has never been an issue, and I can't imagine how bad for me it would have been using Objective-C. I've had 2 top 10 apps in the US app store: "Draw A Stickman" and "Draw A Stickman: Episode 2" (don't worry we are working on more).
If you know C# and .Net your gains in productivity are going to be massive compared to what would happen trying to learn Objective-C. I was a C# .Net developer (Windows only) prior to iOS development and the transition to MonoTouch is great.
If you like Linq, parsing XML in fewer than 100 lines, garbage collection, generics, simple multi-threading, and no weird square brackets, MonoTouch is for you.

I use both Objective-C and c# (MonoTouch & Droid), and I really like both. When I'm coding in c#, there are plenty of features such as Linq which I'd love in Obj-C, & when I'm coding in Obj-C there are plenty of things I'd love to have in c#, but I adapt to whatever I'm coding in quickly enough. Re performance, I've detected no difference at all, even for fairly graphic-intensive stuff, so I wouldn't use that as a reason not to use c#.
I think it's ultimately down to what you're comfortable coding in, though of course with a well designed cross-platform project, you CAN have fully cross-platform core code if you use Mono, and you'll only have to do the UI stuff in a platform-specific way - when it comes to this obviously you'll need to know the native stuff to get your UIs working in a way which is appropriate to the platform and familiar to its users.

We have a line of business app that uses MS SQL as a data store, and has WinForms and web UI's. It integrates with our windows mobile 6.5 and tablet apps with web services. All c#.
We've fully committed to MonoTouch after some experiments in Objective-C and HTML-5 (we had working prototypes): we get to re-use our business logic, and we're comfortable developing new code in c#.
Our business logic is constantly being enhanced, and these enhancements are immediately visible to the mobile app - without having to replicate the logic in Objective-C or C++.
Our main issue is finding a c# programmer who's comfortable with the iPhone and iPad UI's.
MonoTouch is stable and we've encountered no limitations (we're binding to the same iOS API that Objective-C binds to). During our learning curve, we've had question, bumped into bugs and have had some misunderstandings - but the support from Xamarin is superb.
Performance has been a non-issue - our app is snappy even though it's doing a lot behind the scenes.

No body can tell you for sure what will apple support and what it will not support in the future, however apple had some issues with mono in the past, and since history tends to repeat itself, then it may be a possibility of that to happen again
Having said that, always go with the native application development SDKS and environments, it will be more flexible, and it will be updated real time, and performance will always be better in the native

Related

What programming Shapr3D ipad app is written in?

What programming Shapr3D ipad app is written in?
I doubt it would be in Swift?
Previous versions of Shapr3D relied on C++ framework Open CASCADE Technology, and latest versions use Parasolid API (Parasolid kernel become available on iOS much later than open-source OCCT), which is referred as C-callable in some references. So I would guess that many portions of application should be written in C++.
The bindings to UIKit, however, should be written in either Objective-C/C++ or Swift, as Apple left no other choice to developers. The latter one requires more efforts for incorporating C++ code and I don't know if Swift gives any solid advantages over Objective-C++ for GUI development to make these extra efforts worthwhile.
These are just my guesses for a closed-source application.
I think that asking the same question on application's forum would have more chances to get reliable answer (although I barely see any use of such knowledge).

How to set up and use j2objc

I would like to start off by saying that I am a novice programmer. I have only learned Java and Android studio, and I know very little about cmd prompts and that sort of thing. I recently found j2objc which can roughly translate my java code to objective c, and hopefully make it easier for me to transfer my app to ios. I also know there is a gradle version. For some reason, there is no "tutorial" on youtube about setting up any type of j2objc. My Android studio project is on my Windows 8 desktop and my IOS xcode app is on a VM running IOS 10.13. Can anyone help me get this working? (I may need you to explain things to me like I'm 5).
I'm sorry, but as the project lead for j2objc, I don't recommend you use it. j2objc has more benefit as the amount of shared client-side grows, so smaller apps go through a lot of pain for very little benefit. Our most successful client apps tend to be huge (think Gmail, or the Google Docs apps), written by large teams of engineers.
What I encourage is that you initially focus on sharing code on the server-side, with your apps providing the user interface but doing very little calculation on the client. If profiling your app shows it is slow due to network accesses, then you might consider caching or some other local code. If you keep all the interesting/changing features on the server-side, then small, lightweight clients require much less work even if they are rewritten for each new platform your team supports.

What are the advantages of iOS 5.0 storyboarding over traditional UI layout?

I am a total beginner in iOS development. However, I've done Java, PHP and Javascript at work for severals years, so I am pretty experienced with OOP and design patterns.
Xcode 4.2 adds the new storyboarding capability for laying out interfaces in iOS 5.0. Is storyboarding simply a wizard for beginner developers or does it have advantages for more experienced developers as well?
My coworkers and I (both beginners in iOS development) are debating whether one should learn and program iOS using traditional NIBs vs storyboards. What are the advantages that storyboarding provides over previous ways of laying out iOS interfaces? Are there disadvantages to this approach?
Learn the old way in case you have to do both (or read some legacy code). This goes for Arc too; I shudder to think of new Cocoa/Cocoa Touch developers not understanding the old managed memory model.
I think the automated and convenience methods will always cover the "common" cases, and that story-boarding is an example of that. A convenience which greatly simplifies and accelerates the development process. However, there will always be cases where these methods do not provide you with all you need in a given, unusual situation. Just like using the UI elements does not stop developers from going under the hood with core graphics, core audio and so on when they need to. It is definitely, I think, a part of the future of iOS development, but only being aware of that part would be a handicap. So would not being aware of it.
I, personally, dislike automated tools. I have no idea what happens below, what sort of surplus code is inserted, the style of code is not mine and hence I need to work on another person's code. I'm the one that needs to support it for rest of time, not whatever automated tool I may have used.
It is all the tedious abstractions that will help you understand what is going on, especially when you are new to a field.
I'm personally like the traditional nib file approach, where I have more control over its behavior programatically and not having to hack the stroyboard backward to get things done. And of cause, if you have few developer working in a project, it's always good that you don't have to spend time merging changes (since you have several nib file compare to storyboard file)
storyboard files seem to be more readable than xibs.
both are xml files but the xibs seem to have unnecessary baggage and complexity.
I have compiled a list of about 15 reasons against using Storyboards: When to use Storyboard and when to use XIBs
Also, here's a tool that takes some of the pain away: http://github.com/jfahrenkrug/StoryboardLint

How to handle legacy app?

I have inherited a legacy app written in C++ (VS2003) MFC that was not updated in years.
I have limited experience in C++, being mainly a Delphi developer. All other apps of the company are written in Delphi.
Going forward, I see a few choices:
1) Keep the app as is and become a C++ MFC developer. But I don't like the idea of using an outdated technology (MFC) for years to come, trying to keep up with new Windows versions and UI standards. It somehow feels like making several steps backwards and I don't think this is the best way to go (?)
2) Convert the app to any modern UI technology offered with C++ and become a C++ developer, but at least using modern technology. Might be a lot of work, not sure.
3) Rebuild the app from scratch in Delphi, where I will be a lot more productive thinking about the future. It's a lot more work right now, but it might pay off later.
Obviously, I personally prefer 3) but I would like to know from your experience which way is the best for the product.
It's a long term decision to make and I will have to stick with it, therefore I don't want to rush into one direction.
(I have intentionally not tagged this question as C++, trying to get answers from Delphi developers in similar situations)
EDIT:
Thanks to all for your answers.
After learning that it is possible to switch to C++ Builder with a MFC application, this seems to be the best solution.
It combines the least amount of modifications to the current app with the possibility to go forward using the VCL for future GUI improvements.
EDIT2:
It's not possible to combine MFC and VCL in one app, therefore C++ Builder won't be an option. (thanks David for pointing this out)
In general everything depends on how complex the application's logic is and what is the projected life time of the application. If it requires maintenance for another 20 years, then
I'd rewrite the UI in Delphi and move the business logic into C++ DLL (for beginning and possibly rewrite it in Delphi either). Then it can turn that the application can be maintained this way for another 10 years and relatively easily ported to other platforms if needed (less work would be required).
This is a hard question to answer generically. Can you provide any more information about your specific app? What sort of technologies does it use? How separated is the UI from underlying layers and logic?
Some general-ish points though:
Rewriting an app is generally a bad idea, for the following reasons:
It's surprisingly hard to get an accurate idea of the requirements. You're sure you know what it does (after all, it's right there in front of you!), but then you release your rewritten app and you get complains that functionality you didn't know was there is missing, that functionality is harder to access if you've changed something, etc.
It introduces bugs. The code, especially if it's old, is full of bugfixes, tweaks, etc. You will lose all that if you rewrite, especially if it's a different language and you can't reuse any code at all.
When using a different UI layer (MFC to something else) separating the UI can be very hard if the app wasn't written well in the first place. You will probably end up doing a lot of refactoring, even if you don't do a complete rewrite and simply move from MFC to 'something else'.
MFC is kept up to date (ish) - there is a MFC Ribbon control, for example, as well as modern controls and Windows 7 support. The least amount of work, probably, would be to upgrade to a modern version of Visual C++ and become a C++ developer. However, you're quite right that MFC is an old technology and is unpleasant to use, not only because of its design, but also because modern form designers etc are great to use.
You're a Delphi developer. Without rewriting the entire thing, you could consider migrating to C++Builder. Consider this:
You can use old versions of MFC with C++Builder. I've never done this, since the VCL is miles ahead, but it's possible and there are a number of people who do it. Check out this forum, for example. (Credit for that link: this thread.)
Once you have your app compiling and working with C++Builder, you can start migrating to the VCL. As a Delphi developer you'll find using this, even with C++, very familiar. It's the same form designer of course, and using it from C++ is pretty simple - it's a different language but code is often line-for-line translatable. Everything you're used to (DFM files, units, event handlers, etc) all translate.
Not only that, but Delphi code can be used in C++ projects. Just add the units to the project, and in your C++ code include the auto-generated unitname.hpp file. You can't (easily) use C++ code from Delphi, but you could create new modules in Delphi and use them from C++. As you do this, more and more of your app will slowly become Delphi code - ie, you don't need to rewrite in a different language all in one go.
As a Delphi developer, I'd suggest going the C++Builder route. Get it working with MFC, and then migrate your windows to the VCL. At that point, you could start rewriting modules in Delphi, or you may find yourself comfortable enough in C++ to continue developing as is.
Edit: I noticed in a reply above you like the idea above of making it a C++ DLL. The link I gave a paragraph or two above of using C++ object from Delphi might be more applicable than I thought. It would fit the RAD Studio (mix of C++ and Delphi) method as well.
Keeping the app as is, tying you to MFC, is likely not very productive - You'll need to learn a GUI toolkit you'll most likely never use for something else (Delphi is great for GUI, MFC doesn't even come close IMO), in addition to a new language.
That leaves you with the choice of rewriting it in a somewhat unfamiliar language using an unfamiliar GUI toolkit, which'll take a lot more time than rewriting it in a familiar language using a familiar GUI toolkit. So you should just get started porting this to Delphi.
Rewriting C++ code in Delphi isn't as easy as you think. A better way to rewrite it is by just redesigning it from scratch, without looking at the old code. Feel free to look how the old application worked, so you can rebuild it. Just don't look at the code. That way, you should get a more modern result.
Of course, if you use the RAD Studio then you have both the C++ as Delphi compiler, thus it should be able to continue to develop the C++ application, although this means you have to learn C++. Then again, any good programmer should be able to just move to another programming language and learn to use it within 2 weeks to a month. C++ can be complex but still, learning C++ and then maintaining the legacy app should take a lot less time than a complete rewrite.
Do keep in mind that any generic C++ application should be able to be compiled for any platform, although the MFC will probably restrict this to just Windows. Still, it's a language that has an even better backwards compatibility than Delphi!
But to keep in mind, will this app run on a different platform in the future? Should it become a .NET application? Or run on Linux? Should it support tablet computers? Android? Your choices today might be outdated again in two years. And since Delphi has a bit uncertain future right now, mostly because C#/.NET became so popular, you might have a more safe bet with C++. Try to replace the MFC libraries with a more modern UI technology, preferably one that's available for multiple platforms, and think very, very well about the future usages of this application.
In general I'd say:
If it's a tiny tool application, and it takes just a couple of days to do a full rewrite: go for it. Don't waste your time creating dll wrappers or to interface with the existing code in other ways. Just do a full rewrite and be done with it.
Otherwise: you'll probably be making changes in one specific area of the application at the time only. Unless the code is a complete spaghetti, you could even get away with making some local changes without fully understanding the implementation details of the rest of the code.
In any case, you need to invest some time into understanding the application and its language + frameworks.
You have a great opportunity to learn C++ and MFC. Take advantage of it. When Delphi goes astray you will have the required knowledge to keep on coding with a language that won't go away so easily, and you can even broaden your development horizons to areas Delphi (and C++ Builder) will never reach. MFC is no more outdated than the VCL is (although I agree the original design is worse).
Good UI programming has nothing to do with the ability to drop controls on a form visually. Many great applications are not built that way. Actually, trying to rewrite it in Delphi could bring you issue in the future, as long as Embarcadero delivers slowly, and without a credible roadmap.
I recommend
1) Keep the app as is and become a C++ MFC developer. But I don't like the idea of using an outdated technology (MFC) for years to come, trying to keep up with new Windows versions and UI standards. It somehow feels like making several steps backwards and I don't think this is the best way to go (?)
Since MFC is well supported and keeps going with the time. MFC is also a what-you'd-call intrusive framework, meaning that the framework dependencies are usually not easily refactored. (The author of CPPDepend published some nice stats on that IIRC, but I can certainly vouch for this from my own experience with large MFC applications).
If you're gonna rewrite to any modern UI framework, don't code the UI in C++ (judging from the fact that Delphi is an option, it is not about realtime visualizations or something like that).
(I'll unask the unasked question here: I you're gonna rewrite, XXXXXXXXXXXXX?) please gentle(wo)men, let's not do the flame
Does the app come with a descent amount of automated tests? If not you're pretty much stuck with option 1 and hope for the best. If there are many tests you can do a lot more with the code without breaking all kinds of things you didn't know were there.

What do you think of uniGUI, the framework for creating web applications and win32 applications at the same time? [closed]

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 6 years ago.
Improve this question
I've just been redirected by a firend on the uniGUI website. In a previous question I asked about a comparison between Raudus and ExtPascal.
Now this unigui seems to be an alternative to Raudus, that moreover has the advantage of allowing you to compile the win32 exe at the same time with the same source code (of course if you limit yourself to use only uniGUI approved UI components).
I think this is amazing, even if this idea at a first sight willnot make happy all the web apps purists, but in my opionion having this kind of tool is great.
There are many (even small) applications, that can benefit for this code once, get a double UI.
Anyway which are your feelings about this? Do you think it has a future?
ADDITIONAL NOTE: In order not to start a general discussion please try to answer by mentioniong uniGUI specifically, not only a general answer. Thanks.
I started developing uniGUI (or whatever name it may adopt in future) around two years ago. Since then it has evolved a lot. Initial version was based on VCL for the Web. With addition of ExtPascal and Ext JS it has become a very advanced tool to develop Web apps based on Delphi.
uniGUI simply defines itself as a Web Application Development framework. The concept of Web Application has been controversial since its first inception. Some people claim that Web is stateless but applications are statefull, one should not mix these two. However, nowadays with an increasing demand for web applications such notions only remain as a philosophical point of view.
More and more people want to access their desktop apps from the internet. Companies want their local accounting software to be accessible to other branches. A security company wants a web gateway for their access control software. These are all examples for the increasing demand for web apps.
We can consider uniGUI as an abstraction layer for Delphi VCL controls which extends them to the Web. Like all other abstraction layers it helps developer to focus on application logic rather than the development tool itself. It tries to fully integrate the RAD approach into Delphi based Web development.
Dual nature of uniGUI is simply a plus. I'm referring to its ability to deploy same application to both web and desktop using same codebase. This feature maybe useful for some developers but useless for others and it can be completely ignored by those who focus on Web development only.
As for the scalability, the best target for uniGUI and other similar tools seems to be the intranet where the number of clients are predictable and connection speed is a non-issue.
That said, nothing prevents developers from developing web apps that target the internet. At end it is all Ext JS on the client side and Delphi event handlers on the server side. It all depends on how smart you design your app and how efficient you manage your resources. If each of your sessions consumes 10 MB of memory then you're likely to run out of memory very soon.
In conclusion, this framework will have a group of users which will find it best for their needs. There is no black or white here only big gray areas. Like any other tool it depends on the company, the particular project and the available deployment options to see if it is the right tool for you or not.
Web applications are very different from GUI ones. Mixing two approaches for something
more serious then simple form or several buttons I think is just wrong.
I think that the UniGUI idea is a great one. But I think that Embarcadero is the one that should offer that as one more option for developers instead of a independent one. Delphi developers always wanted an easy way to create web applications, and sincerely WebBroker is very poor.
Anyway which are your feelings about this? Do you think it has a future?
The general idea definitely has a future, if only in the PT Barnum sense. This particular implementation doesn't seem to be anything special - there's nothing in it that grabs me as being a great solution to any of the problems I currently have to deal with. But then, I see thick client apps, especially traditional Delphi 2 tier apps, as quite different from web apps.
I'd be more interested if uniGUI worked the other way, and provided a solid MVC framework for Delphi, then extended that to the web. That way you could more easily have your data + business logic + GUI in three connected pieces, rather than the traditional Delphi/RAD problem that business logic gets all tangled up in the GUI, then the web application is a pain to develop because the layers "have to be" separated. This smells like "solving" that problem by letting you leave the business logic mixed into the GUI when you move to the web.

Resources