An iPad application is already developed, which has to support iPhone version as well now. According to apple standards, we have to use size classes in order to achieve that. But I am confused how to manage the universal storyboard with version control(SVN), when working with a team. Different people has to work on the same storyboard. Can anyone give best approach to handle this case?
Related
I am looking for a UI framework that can help in providing end-user experience on different platforms using a single code-base. The platforms I am targeting includes Windows, Android (phone, tablet, tv, watch), Chromebook, Linux, macOS, iOS, iPadOS, tvOS, watchOS etc.
Does anyone have any suggestions on what all frameworks are present out there that can be tried ?
Thanks in advance !
You can take a look at AlterNET UI, it's a cross-platform .NET UI framework, primarily targeting desktop applications development.
It's still in the early betas, we're about to release beta 2 with WPF-like features like support for layouts, bindings, dependency properties, routed events and handling keyboard/mouse input.
These are other frameworks we looked at before coming up with own solution: JavaFX, Electron, Qt, AvaloniaUI and MAUI, you may read a bit more information here.
We have an android application and want to recreate it for cross platform.
What are the facts for or against Xamarin native and forms?
The advantage of native would be, we could reuse all the xml-layouts while we have to recreate the iOS view in either XAML or XIB?
Is there anything what is really a blocker?
I'll comment based on Giorgi's answer with some actual insight and refer to the copied bullet points:
This is a resume of the experience i've gathered in the past 6 months:
Xamarin.Forms is best for:
Apps that require little platform-specific functionality
Wrong. With DI you can use any device functionality you could possibly want. Check out XLabs on GitHub if you doubt this.
Apps where code sharing is more important than custom UI
Kind of nonsense really. You can write your own renderers to represent controls of each platform in the way you want. I've also written more difficult renderers for custom controls such as a SideDrawer. In android i was done in 2 days, iOS about 2 weeks (android renderer was just a wrapper for the native control)
Developers comfortable with XAML
well yeah and anyone who enjoys convenient UI development. Mind you that there is a learning curve with xaml (which i already knew at the time i started from WPF development). But from what i have seen it's not that different from android.
Xamarin.iOS & Xamarin.Android are best for:
Apps with interactions that require native behavior
While hacking your solution up natively is certainly faster you can instead be done rather quick if purchase good controls / know a good native implementation and mirror it in C#, since the API in C# is very similar to the native one.
Apps that use many platform-specific APIs
Not sure why Xamarin is doing anti advertisement against forms. I had little trouble with it so far
Apps where custom UI is more important than
code sharing
Probably true, but it's also harder to keep UI functionality inline and you will need more manpower.
Things to consider about forms:
Forms seems to be stabilizing at the moment and i am sure Microsoft will do their best to turn it into a solid, reliable product (build issues have been a nightmare in the past sometimes, but it has gotten better over time)
The XAML for Xamarin is less developed compared to WPF XAML, though very similar. Recent nuget updates however provide mirrored functionality at an impressive rate. The vast majority of features you expect and love about XAML are present.
List performance is bad if you don't do your research (here). Performance increased loads in that area.
If i had to make the choice again i'd still go for forms. While there are sometimes things which seem flawed / bad you can usually figure out a clean fix somehow, while spending most of your time actually developing the app. (sometimes you will still find things which just make you frown why something isn't implemented, like the Margin property being implemented only just after microsoft purchased xamarin)
If you end up having a requirement of nested lists, make sure to have a look at embeded native controls in order to achieve the maximum performance - this was essential for a product i was working at. See this
According to Xamarin.Forms main page:
Xamarin.Forms is best for:
Apps that require little platform-specific functionality
Apps where code sharing is more important than custom UI
Developers comfortable with XAML
Xamarin.iOS & Xamarin.Android are best for:
Apps with interactions that require native behavior
Apps that use many platform-specific APIs
Apps where custom UI is more important than code sharing
Giorgis answer is the right one, but since you added some more constraints here are my thoughts.
I would analyze the current app. How much code is business logic which can be shared? How customized is the UI, should it look more native or more the same and how will it change in the future? If you plan to change a lot in UI and platforms should look similar, it might be easier to switch to forms.
Also consider if are you planning to develop for Windows Phone? If yes, you might save a lot of time just for this third platform.
After all there is one thing which I would also keep in mind. Developing in Xamarin.Forms does not mean, you cannot develop native. It is just an additional framework. In worst case you can still do everything natively.
Personally I use Xamarin.iOS & Xamarin.Android with MvvmCross, that way I can keep full control of the native UI on each platform while maximizing code reuse.
From Xamarin website (who knows better than them?):
Xamarin.Forms is best for:
Data entry apps
Prototypes and proofs-of-concept
Apps that require little platform-specific functionality
Apps where code sharing is more important than custom UI
[https://developer.xamarin.com/guides/xamarin-forms/]
With Xamarin.Forms at runtime, each page and its controls are mapped to platform-specific native user interface elements.
With Native Xamarin.Android and Xamarin.iOS apps leverage platform-specific hardware acceleration, and are compiled for native performance. This can’t be achieved with solutions that interpret code at runtime.
"Xamarin.iOS - The best way to build native iOS apps."
Ship native app bundles on the App Store. Our Ahead-of-Time (AOT) compiler compiles Xamarin.iOS apps directly to native ARM assembly
code, meaning your app is a native platform binary.
Access any iOS API. We bring 100% of Apple’s iOS SDK to C#, enhancing Objective-C APIs with stronger types and .NET naming
conventions so you feel right at home.
Call existing Objective-C code from C#. Use your existing Objective-C code, frameworks, and custom controls in your Xamarin app
using our automatic binding generator.
Build WatchKit apps. Use Xamarin Studio or Visual Studio to build new Watch Apps, edit Watch user interfaces in the iOS Designer, and
debug Watch apps in the iOS Simulator.
Stay up-to-date with Apple. We released same-day support for iOS 5, iOS 6, iOS 7, and iOS 8 so your apps can take advantage of the
latest iOS features as soon as possible.
[https://www.xamarin.com/platform]
"Xamarin.Android - The best way to build native Android apps."
Ship native Android packages. Xamarin.Android uses just-in-time compilation for sophisticated runtime optimization of your app’s
performance, meaning your app is a native Android APK.
Access any Android API, including new form factors. We bring 100% of Google’s Android APIs to C#, enhancing Java APIs with async support
and .NET naming conventions so you feel right at home.
Call existing Java code from C#. Use your existing Java code, frameworks, and custom controls in your Xamarin app using our
automatic binding generator.
Build Android Wear apps. With access to 100% API support for Android Wear, create full-featured applications capable of running on
Android Wear devices. Stay up-to-date with Android. Xamarin stays
up-to-date with the most current APIs from Google, so you can always
use the latest features in your apps.
[https://www.xamarin.com/platform]
I am working on a consulting gig in which my client got a prototype for his App to work on Mac OS X 10.10 (Yosemite) by using a storyboard. However the App crashes on 10.9.x and earlier, because the APIs required to use storyboards in Cocoa desktop applications were not yet available.
At present the application is not very complex, so I could satisfy his immediate requirement by revising his application so as not to use storyboards at all, I would instead implement his UI "The Old-Fashioned Way", without using storyboards at all.
I'm not real sure what is the best course of action. If I implement what I just said, he will eventually find his UI deprecated by Apple. If I use a storyboard for 10.10 and later, but not on 10.9 and earlier then there could be twice as much work for my client to develop this code.
Note that, as a consultant, I could stand to gain by increasing my client's workload. I don't want to do that as I regard it as unethical to take advantage of my clients by writing bad code. I really want to do right by this fellow.
Right. Storyboards are only available in MacOS X from 10.10 (Yosemite) onward. Support for storyboards is feature of the Cocoa framework, so the fact that it doesn't exist on versions <= 10.9 means code using storyboards won't work.
I'm not real sure what is the best course of action.
I think the most reasonable solution is to explain the situation to your client and let him decide. It's going to be a long time before .xib-based code goes away, if it ever happens, so sticking to .xib files for now is not necessarily a bad choice. On the other hand, your client might prefer to have the most forward looking app you can build, and he may not care all that much about supporting older OS versions. (Several sources indicate that as of early 2015, about half of all Macs are running Yosemite.) You'll serve your client best by giving him the information he needs to make a decision and then writing the app in accordance with his wishes.
I want to update my developing knowledge from iOS to Mac for distributing my apps to Mac App Store.
What are the differences? What are the limitations?
For example, if I want to port my iPhone app that syncs contacts with social network the various NSRequest or ABAddressBook are the same? It changes only views and corresponding view controllers?
Does exists some sort of "adapters" from iOS to Mac to easily convert iOS apps to Mac?
In general, what challenges Mac apps arise respect to iOS apps?
Thanks
If you've gathered some experience you will get along with mac development in no time. Mac and iOS have many things in common, however there are some gotchas, not all of which are visible at first glance.
The most obvious difference may be the use of viewcontrollers - cocoa for mac knows viewcontrollers, however they play a different (and less important) role.
I think the best approach for you would be to take a quick look at the Cocoa Application Tutorial and the Cocoa Fundamentals Guide. Most of it will appear familiar to you. Other than that I'd suggest to not port that project over, but use it as a opportunity to learn mac dev and recreate it from scratch (if it is not too complex). Of course you can copy paste many of the logic stuff, no need to reinvent the wheel.
By the way, I started out developing for iOS too and I found it to be very easy to get used to cocoa mac.
As to your question regarding NSURLRequest (I think that's what you meant, theres no NSRequest in either platform), they are almost the same. Just look it up in the reference library. I found it very helpful to have the iOS and mac os reference library available at the same in my browser, so I could look up differences quickly.
I have iPhone application in the App Store. Do I have to compile my app with iOS 4.2 SDK in order to allow it run on iOS 4.2 devices? Or compiling using iOS 4.2 is required only to allow using new features of new iOS?
I will appreciate if you can clarify this issue...
Thanks!
Yoash
Do I have to compile my app with iOS
4.2 SDK in order to allow it run on iOS 4.2 devices?
No, it will run on the new firmare just fine. At least if the new firmare does not reveal some bugs in your code (which happens).
You don't need to recompile it to let it run on newer OS versions, but like you already guessed, you need to recompile it when you want to use the newer features (eg. AirPlay, "Multitasking" etc).
The old version should still run.
The app might not play well with new features like multitasking on iPad, so it is worthwhile trying to get some testing and feedback done as soon as you can in case there are issues.
If you download the XCode 4 pre-release from the developer portal, you can use the new static analyser to look for problems in the code: this is not just for SDK issues but also things like memory leaks.
Apple recommends that you always compile with the latest SDK, even if you are targeting older versions.
Unless you run into a specific issue that is causing incompatibilities, it is wise to take this advice. A lot of small bugs and performance issues are fixed with each new iteration of the SDK.
That being said - you can continue to use the older SDK's, and Apple will still accept the apps you build. For mature apps that are only going through minor tweaks, this is probably the safest course to avoid introducing new bugs.