Expediting native mobile application development within time and budget constraints is difficult. With the persistent need to improve customer experience and increase developer efficiency, many enterprises have turned to the speed and ease of web development to keep up with demand—a resource that many of them already have. But maintaining native mobile and web code bases and achieving parity between the two can add complexity to an already complicated organizational structure. 

iOS and Android Web Views to the rescue. Or so you might think.

Web Views brings two teams together—web and native—to build mobile applications faster and more efficiently. They allow for web content to be embedded into native applications, typically by breaking up the native application’s front end into feature slices, or micro frontends. By embedding web content, developers can focus on building fantastic user experiences while leaving the content development to the web team. This also ensures web and native parity; as web features are updated, the web content embedded in the native app is also updated from the same code base.

Development kits from Apple and Google provide stock Web Views for native app developers to start using right away. These out-of-the-box experiences seem like the ideal solution for bringing web and native content together to build and scale mobile apps, but there are many factors to consider when using stock Web Views in your app infrastructure.

From usability issues to feature limitations, here are the things you should be considering.

Usability of iOS and Android Web Views

Large, global enterprises like Apple, Amazon, and Netflix have been using Web Views for years. By embedding web content into their native apps, Apple can update their music catalog without relying on native teams to build the content into the native app. Similarly, Amazon uses Web Views to update their millions of product offerings, and Netflix updates their movie and TV show database with ease using Web Views. Though stock Web Views enable these companies to dynamically update their apps, the setup and maintenance to make this happen smoothly requires a number of talented developers and time.

Web Views don’t come with any features

The basic functionality of a stock Web View is to break up the native app into micro frontends. But what if a native development team wants to communicate between the web and native layers? That has to be manually built. If developers want to maintain native component interactivity with the web content, they need to build that too. 

“With iOS and Android Web Views, handling delegate methods for navigation, load, errors, permission requests, and other general housekeeping all need to be built manually,” says Max Lynch, CEO and co-founder of Ionic.

In other words, customizations need to be built to provide a seamless experience that makes the native application and web content truly feel native.

Imagine an engineering manager decides to dedicate the time to make custom-built Web Views. Their team establishes the communication between the web and native layers, builds a system to ensure native component functionality with the web content, and develops custom native navigation controls. This effort could take weeks to build and test, and this lift only accounts for one code base. This whole process needs to be repeated for every mobile application on every platform.

“Developers have to learn two different APIs, iOS WKWebView and Android WebView,” says Vivek Mano, director, product specialist at Ionic. “On top of that, development teams have to account for various mobile OS versions.”

Stock Web Views introduce loading delays and network dependencies

Pulling web content into a native application through stock Web Views loads the content from a remote server rather than locally. This means a poor user experience if the user’s internet connection is slow, intermittent, or loses connectivity altogether.

In addition, there is always an inherent lag whenever content is pulled from a server, even with the best internet connection. A major airline recently discovered that using custom Web Views slowed app performance by 2-3 seconds because the web content took a long time to load. 

While stock Web Views can save development time and effort and ensure parity across web and native applications, they can just as easily counteract that progress.

Alternative to stock Web Views

Stock Web Views, for all of their promise to improve the app development experience, lack in many areas. That’s why we built Portals. 

Ionic Portals saves development teams countless hours required to custom build Web Views to fit their app needs. Portals handles all of the configuration and maintenance without the hassle by offering:

• Full access to native device features
• A fully supported stack with JS compatibility
• A large library of Ionic and community plugins

In addition to the built-in features provided out-of-the-box, Portals’ Web Views are on-device, meaning the content is downloaded to the device rather than accessed from a remote server. This improves loading speed significantly and doesn’t rely on server access to pull in data. The same major airline mentioned earlier reported a 2-3 second app speed improvement with Portals.

Interested in learning more about Portals?

If you’re considering moving your native applications to an architecture that supports iOS and Android Web Views, Portals may be for you. Reach out to an App Specialist to discuss your company’s needs and activate a trial.

The post Limitations with iOS and Android Web Views appeared first on Ionic Blog.

It’s a Christmas miracle—Bootstrap v5.3.0-alpha1 has arrived just in time for the holiday break! This release brings new color mode support, an expanded color palette with variables and utilities, and more.

We’re keeping things short and simple in this blog post with deeper dives into the new color modes and more coming in future posts. For now, we want you to enjoy the holiday break and come back next year feeling refreshed and rejuvenated. Keep reading for what’s new and we’ll see you next year!

Dark mode and color modes

Bootstrap now supports an explicit opt-in for creating multiple color modes via the data-bs-theme attribute on the root <html> element. We opted for a data attribute solution so that you can create any number of themes instead of just light and dark. We use a new Sass mixin, color-mode(), to generate our dark mode styles with either a data attribute (the default) or a media query. The latter is useful if you only have two color modes and want automatic color mode changing via CSS.

Read more in the new color mode docs.

For those wanting to build something more advanced, you can read how we built our own color mode picker with JavaScript that respects the device or operating system setting by default, but still allows someone to override it with an explicit theme.

If you’re using the CDN or starter template, using the new color modes is straightforward. Add the data-bs-theme attribute with light or dark values to the <html> element and you’ll be using either the light or dark theme.

Want to use CSS media queries to change the color mode instead? You can also build Bootstrap with Sass and customize how you use color modes. Read the docs to learn more. You can even create custom color modes.

Expanded color palette

We have a huge new color palette update with new Sass variables, CSS variables, and utilities to boot. Foreground and background colors have new secondary, tertiary, and emphasis colors to choose from, while our theme colors have expanded on to include their subtle background colors, subtle border colors, and darker text colors. We’ve rebuilt some components (like list groups and alerts) to use these new variables in their source Sass and compiled CSS so that they respond to the color mode changes.

Check out the new colors docs.

And more!

And a few more noteworthy changes:

• Added new CSS variables for grid breakpoints, link colors, close button, alert links, forms, and more. In addition, many components have been updated to use more global CSS variables like --bs-border-color to better respond to changing color modes.

• Floating forms have been updated to be more bulletproof and now include proper support for textareas.

• Added many new utilities, including fw-medium, overflow and object-fit utilities, z-index, and more. Plus, border-radius utilities have been updated so that you can combine .rounded-{top|bottom|start|end} with .rounded-{0-5|pill|circle}.

• Fixed some Popper tooltip and popover consistency issues.

Be sure to consult the v5.3.0 migration guide to see what’s changed as well.

Up next

As we iron out the release with your feedback and bug reports, we’ll also be updating the Bootstrap Blog and Bootstrap Icons sites to use the new themes soon. We’ll also continue to refine how our components and utilities work with the new color modes, adding Sass testing to improve our coverage of how folks build with Bootstrap, and much more.

Get the release

Head to https://getbootstrap.com for the latest. It’s also been pushed to npm:

Read the GitHub v5.3.0-alpha1 changelog for a complete list of changes in this release.

Support the team

Visit our Open Collective page or our team members’ GitHub profiles to help support the maintainers contributing to Bootstrap.

Happy Holidays from everyone here at Extly!

The Ionic team is looking forward to the New Year and welcoming in 2023! To get the party started, we’re giving our Ionic account login and signup experience a totally new look.

Starting today, the login and signup pages will be customized based on which products you’re accessing—whether it’s building apps with Ionic, creating micro frontends with Portals, or automating app delivery with Appflow.  Also, the location of both the login and signup pages will be moving from ionicframework.com to ionic.io.

To make sure you can still access all of your favorite Ionic products, here’s everything you need to know:

• We gave the login page a crisp new look for 2023
• The login page for accessing your Ionic account can now be found at ionic.io/login
• Users navigating to the old sign-in location (ionicframework.com/login) will automatically be redirected to ionic.io/login
• You’ll see a different look and feel depending on where you’re signing in from

• You may wish to update any bookmarks you may have for the login page
• If you have whitelisted the ionicframework.com domain, be sure to also add ionic.io so you can continue accessing Ionic’s cloud services
• When logging into the new login page for the first time, you will need to re-enter your user credentials (username and password)
• If you are using a password manager, you should update your saved login information so that it’s associated with the new login URL

We hope you all enjoy the new page. If you have any feedback, comments, or suggestions, please reach out to us on Discord or via email at This email address is being protected from spambots. You need JavaScript enabled to view it. – We love to hear from you!

The post A Fresh New Way To Access Your Ionic Account appeared first on Ionic Blog.