Both android and ios

7 Best Frameworks & Libraries for Cross-Platform Android and iOS Apps in 2021

with links to relevant online courses and tutorials

Hello guys, there is a huge demand for developers with knowledge of cross-platform mobile app development frameworks like Flutter and React Native. This is obvious as no one wants to maintain a separate code base for their Android and iOS mobile app.

Having a separate code base is a maintenance nightmare because you have to work twice to put a bug fix or feature into each of your codebases.

Thankfully, Flutter and React Native solve its problem by allowing you to create a native-looking mobile application for both Android and iOS devices using the same code based.

While Flutter and React Native are definitely the leading cross-platform mobile app development framework, they are not the only ones as you also have frameworks like Ionic, Xamarin, and Native Script which you will learn in this article.

5 Best Frameworks to build Cross-Platform Mobile apps

Without wasting any more of your time, let’s dive into the best framework to build cross-platform mobile apps. We’ll also look at the pros and cons of each framework and which you can use based upon your strength. I will also mention relevant courses along the way for further learning.

1. Flutter

This is an excellent framework for developing cross-platform native mobile applications in 2021. Like Golang, TensorFlow, and Angular, Flutter is also from Google, which uses Dart (another programming language from Google) and provides SDK for developing a cross-platform native mobile application.

It’s always been challenging to release your app to different platforms like Android, iOS, and Windows Mobile, as you need to maintain a separate codebase. Flutter solves that problem by allowing you to create mobile apps for both iOS and Android devices using the same codebase.

Flutter has seen a lot of growth in the last 2 years, and it’s now the #1 framework for developing native mobile apps. If you have already decided to learn Flutter and looking for a resource, then I suggest you check out this Flutter & Dart — The Complete Guide [2021 Edition] by Maximilian of Acadmind on Udemy, one of my favorite courses to learn Flutter in 2021.

2. React Native

Apart from Flutter, if there is another framework you can check out for developing native cross-platform mobile apps, then they React Native. It uses React and JavaScript for producing high quality native mobile apps.

It’s the right choice for all web developers who wants to become a mobile app developer and already familiar with technologies like JavaScript and React. If you are one of them, then I suggest you learn React Native in 2021.

Also, there are a lot of resources to learn React Native, both free and paid, but if you ask my recommendation, I highly recommend you check out Stephen Grider’s The Complete React Native + Hooks course, one of my favorite resources to learn React Native online. Stephen is one of the best instructors of Udemy and his teaching style is really great

3. Cordova

Apache Cordova is another mobile application development framework originally created by Nitobi. Adobe Systems purchased Nitobi in 2011, rebranded it as PhoneGap, and later released an open-source version of the software called Apache Cordova.

It allows you to use standard web technologies — HTML5, CSS3, and JavaScript for cross-platform development, and one is of the hot technologies to learn in 2021.

If you’d like to learn Cordova in 2021, then please check out Build iOS & Android Apps with Angular and Cordova, one of the exciting courses for learning Cordova.

4. Xamarin

Xamarin is a way to make mobile apps quickly for all platforms with a single, shared C# codebase, build a custom native user interface for each platform, or use Xamarin.Forms to write a single shared user interface across platforms.

It’s owned by Microsoft and quickly becoming popular for creating mobile apps for C, C++, and C# developers.

If you already know one of the C languages and you’re looking for a career in mobile app development, then I strongly suggest you learn Xamarin in 2021, and The Complete Xamarin Developer Course: iOS And Android! is a good course to start with.

5. Firebase

Firebase is not exactly a cross-platform framework for developing mobile apps but a useful framework for building backend. It’s actually Google’s mobile platform that helps you quickly develop high-quality mobile apps and grow your business. You can choose Firebase as a backend for your Android or iOS application.

If you are looking to move into the lucrative business of mobile application development in 2021, then learning Firebase is a very good idea, and Advanced iOS and Firebase: Rideshare is a good place to start.

6. Native Script

If somehow you didn’t like React Native and Flutter and looking for alternatives, then you can also check out Native Script. NativeScript is a free and open-source framework to develop a mobile application for both Apple iOS and Google’s Android platform.

It allows you to build native mobile apps in both TypeScript and JavaScript and using Angular and Vuejs. If you are a frontend developer and already know frameworks like Angular or Vuejs, then Native Script can be the right choice for you.

NativeScript features deep integration with both Angular and Vuejs and allows you to write code on any language, which translates into JAvaScript like TypeScript or CoffeeScript.

If you need resources, I suggest you check out this Native Script + Angular: Build Native iOS and Android Apps course by Maximilian Schwarzmuller on Udemy.

7. Ionic

This is another framework for developing hybrid mobile applications using JavaScript. Ionic also allows you to build cross-platform mobile apps, which means you can create an application for any platform using one codebase.

Ionic Framework is a free and open-source and provides a portable UI toolkit for developing high-quality cross-platforms apps for native iOS, Android, and the web- all from the single codebase. It also has an Ionic React that leverages React for building hybrid mobile apps.

If you want to learn Ionic in 2021, then I suggest you check out this Ionic 4 MasterClass course on Udemy. It’s created by none other than Maximilian Schwarzmuller, one of the best instructors on Udemy and Youtube.

That’s all about some of the best frameworks you can learn for cross-platform mobile app development. You don’t need to learn them all, choose the one which suits your needs.

For example, if you already know JavaScript and React.js then React Native is the best framework for you but if you are coming from Dart background or don’t mind learning a new programming language like Dart then Flutter is a great choice.

Similarly for developers with C.C#, and C++ background can use the Xamarin framework for building cross-platform mobile apps.

Thanks for reading this article so far. If you like this article useful and find these technologies worth learning for mobile app development, then please share it with your friends and colleagues. If you have any questions or feedback, then please drop a note.

Источник

A Tale of Two Platforms: Designing for Both Android and iOS

Whether you’re working in-house, contracting, or for an agency, companies need apps for many different reasons. Established companies in particular need to cater for their existing customers and the devices they use. Often that means a new app for both Android and iPhones.

In an ideal world, we’d spend months designing two apps. But in reality, many projects don’t allow that much time. For any of the apps I’ve worked on, the deadline has been tight enough for designing one app, let alone dividing the project fully into two.

Quite often you’re designing one app, with tweaks being made before handing it over to two development teams. If you are designing an app in this way, it’s important to understand the difference between the two platforms early on, and the quick ways that you can make the experience feel native to each.

Before You Begin: Choose Your Approach

1. Keep your enemy closer

It’s likely that you will have a personal preference for one system. I’ve always used iPhones, so I have a more natural understanding of the UI patterns on iOS. The first thing thing to do is get to grips with the other platform, and the best way to do this is to buy another device, an Android in my case. It might even be a good idea to use this as your primary device for the length of the project, to really get a feel for the platform.

If you’re working in-house, get them to buy you a test device. If there are any issues, communicate with management the value that understanding the alternative platform will add to your design work (the cost is expensive for two devices out of your own pocket, but for a business it’s a low expense compared to the outlay on the design and development of a new app). If you’re working freelance, you should be able to write it off against your tax bill.

2. Choose a lead

As we’re designing for both platforms at once, whilst dealing with the real world where time is limited, you’ll have to accept the reality of prioritising one platform at the outset. Make this decision not based on your personal preference, but based on the market for your app. Do more people in your market use Android phones? Is it a paid app? What is the target audience? Asking these questions will help you to decide on which is preferable.

3. Know the rules

Read up on UI guidelines for Android and iOS. In the past Apple was known for being more strict with their guidelines. To get an app in the app store, there is an approval process which takes approximately two weeks. There is no approval process for the Play store. However, due to this lower barrier to entry on Android the quality of design has traditionally been worse off. Google are looking to change this with their Material Design guidelines.

The Material Design aesthetic has become very familiar to web designers

There are a lot of good, and free, UI kits which you can use for your projects (you’ll find some listed at the end of this article). Using these components will naturally give your app a native feel. But even when you get the UI kits, it can be tricky knowing where to differ and where to stay the same between platforms, so that’s where I want to help.

Designing Your App

Follow these simple steps, and your app will be on the right track to fit in on both Android and iOS devices.

1. General style

Since iOS7, Apple has shifted to a flatter design style, and ditched the skeuomorphic shadows, textures and effects which defined the iPhone’s early years. Android, having been more systematic in style in the beginning, has gone slightly the other way. Google’s new Material Design guidelines create more subtle references to the real world, with a layered “paper” approach providing more hierarchy.

2. Real buttons

Android phones have a back button, which can be used to return to previous screens in the app.

Get back

iPhones don’t have this button, so there needs to be a way to travel back to the previous screen. This is usually done by a “back” chevron in the top left of the screen, but needs to be considered throughout the various journeys in your app.

3. Global elements

There are global elements (like a status bar and header) which appear on all the pages of your design. You shouldn’t be changing the height or style of these bars at all if you want the app to feel native, so I would recommend defining them once in your first page design for each platform. Then afterwards you can use a placeholder (or the status and top bar from your primary OS) on each of your mockups, but indicate to developers that it should be the same across the board.

There are slight differences between the navigation bars on each platform. On Android the text is left aligned, whereas for iOS it’s centred. On iOS, a lot of companies replace the title of the main page with their company logo, but this is not best practice on Android. The status bar (with your network, battery, and time information) is a native component, and you don’t need to consider the design. Just make sure when presenting mockups to use the correct one to avoid any confusion or distraction.

4. Navigation

Perhaps the biggest point of difference between iOS and Android platforms is navigation. The primary navigation pattern on Android is a drawer menu. Android users naturally go to this for menu items, and it tends to be omnipresent throughout the experience. Apple’s guidelines are more in favour of a tab bar, which is located at the bottom of the screen, and allows easy access to the top level areas of the app. When you’re deciding the top level architecture of your app, you can plan out two separate menus for the two platforms.

Thinking about the architecture of the app is arguably more important than the layout of the menus–a point I made in another article about some of these issues. If your structure is sound, the navigation will follow.

As you see here, there are two navigation patterns: a drawer menu for Android and a tab bar for iOS. It’s sometimes easier to simply hide the navigation layer while you work on individual views.

5. Cards, or not?

Cards are becoming the primary UI pattern in digital design. They’re versatile and allow users to consume quick bites of content in a way that suits mobile behaviours. Visually, cards fit in very well with Android’s material design (it being inspired by paper). Using drop shadows and reasonable gutters between cards will create a native look and feel naturally.

On iOS, using cards needs more care and consideration. Even big apps like Facebook and Pinterest use cards in a way that is slightly out of tune with iOS guidelines. iOS guidelines suggest using depth in transparencies and overlays, but the basic view is usually more flat. Instagram use an entirely flat design style, although each post could be considered a card from an architectural point of view. It’s worth looking at how Instagram gain the same component feel within an iOS style. If you’re going with cards on iOS be very gentle with any use of shadow, and try to keep them as subtle as possible.

Cards for Android and iOS, some dimension lends a bit of affordance

6. Typography

The system font family on iOS is Helvetica Neue. On Android it is Roboto. Although the style of the typefaces are noticeably different, the metrics of the fonts are quite similar. If you’re saving time you’ll be safe enough to work with just one, but communicate to developers to implement the right font for the system. When working with important layouts and extremes in type sizes it’s advisable to at least test out your layout with both fonts.

If you want to go the extra mile, you’ll need to pay closer attention to the typographic and layout conventions on each platform, again referring to the guidelines above. A few generalisations:

• Android Material Design uses ample white space in layout
• There is also more dramatic use of font sizing in material design. Striking headings with lots of space provide the hierarchy
• On iOS, there is less dramatic variation in sizing. But there is slightly more variation in font weights, which still allows you to create a hierarchy.
• Typically, both platforms use lighter weights in the font family. However, in the example below, the Android design is using light and regular weights of Roboto, while the iOS design is using bold and regular weights of Helvetica Neue.

This is a very simple example, to emphasise how even in simple ways the typography can immediately tell you if you’re dealing with an Android or an iOS app.

7. Grids and touch targets

iOS (44px @1x) and Android (48dp — 48px at 1:1 ratio) have slightly differing guidelines for touch targets. Material Design guidelines also suggest aligning all elements to an 8dp square baseline grid.

On the latest project I worked on we found it safer to follow these Android guidelines because (a) the larger 48px touch target is safe for both platforms, and (b) the layout for Material design is more defined and up to date. Either way, you will need a grid to work with, but with Android being more strictly defined we found 8dp to work well. This means setting up your document with 8dp increments in both horizontal and vertical planes to create a tiled grid layout.

8. Button styles

There are several button styles defined in Material Design:

1. Floating action buttons: the most traditionally shaped buttons. The drop shadows are quite heavy and lift them off the page. These should only be used on backgrounds, or sparingly on cards. They shouldn’t be used at all on alerts or popups, as doing so creates too many layers of depth. The primary action takes your accent colour, while the secondary versions are usually a less prominent colour.
2. Flat buttons: essentially text in your accent colour, without any bounding elements. They use padding and all caps case to give them structure.

Compared to Material Design, iOS apps are typically flat in appearance, making no use of depth or drop shadows. The primary buttons have a fill colour, while the secondary buttons are reversed out, using a stroke of the same colour. This metaphor can become somewhat limited, especially when compared to tabs and other elements to follow. To get this very flat style right, it’s important to have clear and consistent metaphors for what colours mean in your app.

iOS also has a plain text style button, but it doesn’t share Android’s uppercase styling, and is lighter in font weight.

9. Action Sheets

Action sheets allow users to choose from a multitude of actions from one UI item. For example, when I touch (or long press) on an image I might want to share, upload, copy, or delete the picture.

iOS and Android deal with this in slightly different ways. Firstly, there are similar action sheets which display from the bottom of the screen, as an overlay on the current view.

With Action sheets, overlays, and alerts, iOS and Android use different details to indicate depth in layers:

• Android overlays have a solid colour with a slight drop shadow to indicate that it is a “paper” layer above.
• iOS overlays have no drop shadow, but have a slight transparency on the background.

Dropdown buttons

Existing only on Android, these are a quick fire method of making a selection. Bear in mind, however, that there isn’t a native iOS equivalent. In the example below, the user presses on “profile” in step 1, and is presented with a simple menu in that location to choose one of the available profiles. These menus are also used frequently from the overlay button in the action bar, indicated by three vertical dots.

Specific Data Input

For particular inputs like date and time, Android now comes with built in dialogues. These look like alert popups, but with UI specifically catered to inputting this type of data. An example is shown of a calendar input. Android has an optimised overlay provided for inputting a date. iOS deals with this quite differently, appearing as a wheel that comes up like a bottom sheet. Be careful in planning these, and communicate with developers early on input components.

10. Segmented controls

Segmented controls are used to switch between different content within a single view. Their use is much the same, but they’re very distinctive visually on each platform so it’s important to use the right style. On iOS there are three tabs, styled similarly to the line buttons discussed previously. On Android, they are denoted by a simple underline, and given a lot more white space to signify their interaction.

11. Alerts

It’s important to get the style of these right because they might control important actions like signing up, accepting terms, or even confirming payment. We want them to feel trustworthy and native.

The Android alerts use the flat button styles that were shown earlier, dimensions for which can be found in the material design guidelines. The actions sit on the bottom right of the alert. The “buttons” are actually entirely text based. They use all caps to give them more structure, and they carry the primary action colour of your app.

On iOS, the actions are separated by dividers. They are usually in sentence or title case, as they gain their structure from the separate blocks. They are centred in the field, and again they will inherit your active colour.

12. Icons

Icon design is quite the specialist area in UI design. Whether you’re using free icons, commissioning an icon designer, or designing the icons yourself, there’s a distinct style native to each platform. iOS popularised line icons, with very thin strokes. The Android system icons have thicker strokes, or are entirely solid icons. In the past, Android icons used perspective or a three dimensional twist, but now their guidelines specify two dimensional icons viewed straight on. Here’s a quick example with several icons for comparision, or use the direct links to icon guidelines for Android or iOS

13. Snackbars, toasts, loading images

Unlucky 13. There are a few UI details that can slip through the cracks. Common ones like alerts and loading icons are often left to developers. You may have experienced rogue spinners and strange alerts which have felt out of tune with the rest of the app. There tend to be native solutions for these, but they can be tuned to the style of your app. This is definitely an area where collaboration with developers is the best way to decide on which way yours should work.

14. Common UI Controls

Radio buttons, check boxes, fields and switches are functional components that should be given a native feel. As with alerts and dialogues, these controls and inputs are an area of trust and familiarity for the user. Use the native components as much as possible for these, so that people (a) know how to use them, and (b) trust your app with their sensitive data or payment details.

In the example below we see switch and radio button equivalents for Android and iOS. Again, the differences are small enough for you to progress with one design, and tweak for the other later, but the subtle differences are essential for a native look. Use your UI kit as much as possible for these components, and again communicate with developers early on in the process.

Android (left) and iOS (right)

Summary

It isn’t an impossible task to create a native feel for your app on both iOS and Android with one design. Try to keep on top of these tweaks from the beginning, keep an eye out for components that feel out of sync on one platform, and always work as closely as you can with developers.

Resources

This article will hopefully give you quick answers on where to diverge designing for two apps, but you’ll also need some tools and templates to properly execute your design. There are lots of commonly available resources that you can use as a starting point, here are some of the best:

Guidelines

If you want to know more, a lot of the information I’ve provided can be found in the platform guidelines. They’re quite extensive, so I’ve just pulled out the parts that are important to compare. But if you have more specific questions this is the best place to start:

UI Kits

These UI Kits will save you recreating basic native controls and matching sizes. You can pluck out the pieces you need and then switch between them for the Android and iPhone output of your designs.

Icons

Even if you’re making your own, or commissioning icons, they’re useful to have as placeholders while you work. Icon design can be a job in itself, and you don’t want icons to slow you down while you get an overall feel for your app. I recently found the links below on icons8 look pretty good, or flaticon.com is great for more general icons.

Mockups

It’s always useful to have device mockups for presenting your app. These come in many categories. You might want a basic device mockup for context, a simplified flat device to let your app shine, or a lifestyle mockup to present a use case. Here are a few resources I’ve found useful, there are many more out there. When it comes to Android devices, be careful which you choose. I would lean towards the Nexus range, as they’re Google’s own phones and won’t hint at a preference towards other manufacturers.

Источник