The essential news about content management systems and mobile technology. Powered by Perfect Publisher and XT Search for Algolia.
The News Site publishes posts to the following channels: Facebook, Instagram, Twitter, Telegram, Web Push, Tumblr, and Blogger.
Configuring and managing build environments is critical in mobile development, but keeping everything organized can feel like a job even Marie Kondo couldn’t handle. Without build environments, ensuring you have the right tools in place to successfully build your app is cumbersome at best. One wrong configuration value and your build pipeline can come to a screeching halt.
A build environment is essentially the collection of dependencies and configurations needed to build your app. Now multiply that by each platform, version, and delivery channel, and you have a lot of environments to manage. Fortunately Appflow, Ionic’s mobile DevOps solution, is designed for easily managing build environments to ensure your app is built and deployed consistently across all platforms.
Appflow manages the dependencies for you by providing build stacks and provides multiple options for easily specifying configuration details.
Mobile teams will typically have multiple versions of their application, such as for testing or internal use, as well as for each supported platform like iOS and Android. Each of these versions will have different configurations, such as:
These are typically managed with environment variables and secret keys that are set for each specific build environment. Managing these manually can be difficult, but Appflow lets you define and store custom environments to streamline and simplify your automated builds.
To create a custom environment, go to Build > Environments. Give your environment a name and provide key/value pairs for secret keys and environment variables for that environment. Keep in mind that secret keys cannot be viewed once set.
Once created, you can choose a custom environment from the Builds or Automations screen to make variables and secret keys available during build time. The environments can be updated at any time, allowing for security best practices such as key rotation.
Appflow custom environments are particularly powerful when combined with Appflow’s iOS Schemes and Android Variants support. Use the `IOS_SCHEME`, `ANDROID_BUILD_TYPE`, and `ANDROID_FLAVOR` environment variables to use a scheme or variant defined in your project, and Appflow will apply it during the build. This means you won’t have to duplicate configurations you’ve already defined in your Android or iOS project.
Read more about schemes and variants here.
For specific configuration overrides such as the app name or bundle ID, or to customize variables for Appflow Live Updates, you can also leverage built-in custom native configurations. Just like custom environments, native configurations can be defined and selectively applied at build time for native iOS and Android builds.
While predefined custom environments make it easy to manage build environments for your most common build types, sometimes you need flexibility for a single build. This is helpful when testing new environment changes before adding them to your regular workflow or for unique one-off changes.
To support this nimble workflow, Appflow introduced Ad-Hoc Environments that allow you to set or override environment variables for a single build. From the build screen, you can pass key/value pairs which apply to that specific build only. These values are not saved after the build, and it’s not recommended to use sensitive data.
If you’d like to create and save a new custom environment from the build screen, use the Environment section.
Appflow custom environments and ad-hoc environments are now available for all Appflow plans. To leverage them for your mobile deployments, sign up for a free account today and start building. If you have any questions about getting started, our team is here to help.
The post Managing build environments in Appflow appeared first on Ionic Blog.
Read more https://ionic.io/blog/managing-build-environments-in-appflow
Hot on the heels of our second alpha, we’re releasing a third (and unexpected) alpha for v5.3.0 today with some fixes for some Node Sass compilation errors. In addition, we’ve added a handful of other updates. We’re still on target to ship our stable release soon!
Once again, if you’re new to the v5.3.0 alpha releases, please read through the Migration guide for the first alpha and last month’s second alpha.
Here’s a look at what’s changed in this quick release:
calc()
functions.--bs-border-radius
variables across
more components..d-inline-grid
utility class..tooltip-inner
placement when using
variations in fallbackPlacements
.$color-mode-type: media-query
.background-color
to help with multiple lines
of text in textarea
s. This also fixes the colors when
form elements are disabled in floating forms.Head to https://getbootstrap.com for the latest. It’s also been pushed to npm:
npm i This email address is being protected from spambots. You need JavaScript enabled to view it.
Read the GitHub v5.3.0-alpha3 changelog for a complete list of changes in this release.
Visit our Open Collective page or our team members’ GitHub profiles to help support the maintainers contributing to Bootstrap.
Read more https://blog.getbootstrap.com/2023/04/03/bootstrap-5-3-0-alpha3/
Today, we are excited to announce the release of Ionic 7! This stable release of Ionic comes after several betas and release candidates with improvements suggested by the Ionic community. Thanks to all of your contributions and the hard work of our team, we’re thrilled to officially bring Ionic 7 to market.
Ionic 7 brings developer experience improvements when working
with overlays, forms, and events! It also brings performance
improvements for Angular, React, and Vue applications. Changes
include:
Read more about the Ionic 7 changes
The Ionic Docs have been updated with the latest usage examples: https://ionicframework.com/docs
We have also added a new “Upgrade Guides” section in the sidebar for developers updating from older versions of Ionic.
With the release of the new Ionic CLI v7, all new Ionic React and Ionic Vue starter applications will use Vite. This tooling replaces the Vue CLI and Create React App tools used in previous starter applications. Since this change only impacts new Ionic apps created with Ionic CLI v7, developers can continue to use the Vue CLI and Create React App tools in their existing Ionic apps.
Be on the lookout for a blog post with more information about Ionic CLI v7 soon!
Developers can follow the Ionic 7 Migration Guide to update their existing Ionic 6 apps.
Looking to start with a brand new Ionic 7 app? Try our app creation wizard!
Please report any issues you encounter on our GitHub repo.
Thank you to everyone who tested or provided feedback during the Ionic 7 beta process. Thanks to you, we have a great product that’s sure to make development easier than ever. Stay tuned, as we have many more great improvements planned for Ionic in 2023!
The post <strong>Ionic 7 is here!</strong> appeared first on Ionic Blog.
Read more https://ionic.io/blog/ionic-7-is-here
Our second alpha release of v5.3.0 has landed with a ton of enhancements and bug fixes for our new color modes! There’s still more to come, but we’ve held off shipping until we ironed out enough issues. Huzzah, we have!
This v5.3.0 release is a monumental update for Bootstrap 5. It’s big enough that it could’ve been a v6 on its own, but we wanted to do right by the community and get color modes out the door without the massive major release upgrade. We’re getting super close now, so bear with us as we continue to chip away at this.
And, in the meantime, here’s the rundown on what’s changed since our first alpha. Have a read through the Migration guide for the first alpha, or the blog post for the release announcement, if you’re just getting into v5.3.0.
Dark mode colors are now derived from our theme colors (e.g.,
$primary
) in Sass, rather than color-specific tints or
shades (e.g., $blue-300
). This allows for a more
automated dark mode when customizing the default theme colors.
Added Sass maps for generating theme colors for dark mode text, subtle background, and subtle border.
Snippet examples are now ready for dark mode with updated markup and reduced custom styles.
Added color-scheme: dark
to dark mode CSS to change
OS level controls like scrollbars
Form validation border-color
and text
color
states now respond to dark mode, thanks to new
Sass and CSS variables.
Dropped recently added form control background CSS variables and reassigned the Sass variables to use CSS variables instead. This simplifies the styling across color modes and avoids an issue where form controls in dark mode wouldn’t update properly.
Our box-shadow
s will once again always stay dark
instead of inverting to white when in dark mode.
Improved HTML and JavaScript for our color mode toggle script. The selector for changing the active SVG has been improved, and the markup made more accessible with ARIA attributes.
Improved docs code syntax colors and more across light and dark modes.
Removed the ability to nest light mode components within dark mode. This was super incomplete unfortunately and just isn’t practical without quadrupling our selectors for every component. Maybe in v6!
$headings-color-dark
or --bs-heading-color
for dark mode. To avoid several
problems of headings within components appearing the wrong color,
we’ve set the Sass variable to null
and added a
null
check like we use on the default light mode.Cards now have a color
set on them to improve
rendering across color modes.
Added a new .nav-underline
variant for our
navigation with a simpler bottom border under the active nav link.
See the docs for an example.
Navs now have new :focus-visible
styles that better
match our custom button focus styles.
Added a new .icon-link
helper to quickly place and
align Bootstrap Icons alongside a textual link. Icon links support
our new link utilities, too.
Added a new focus ring helper for removing the default
outline
and setting a custom box-shadow
focus ring.
Renamed Sass and CSS variables ${color}-text
to
${color}-text-emphasis
to match their associated
utilities.
Added new .link-body-emphasis
helper alongside our
colored links. This creates a colored link using our
color mode responsive emphasis color.
Added new link utilities for link color opacity, underline offset, underline color, and underline opacity. Explore the new links utilities.
CSS variable-based border-width
utilities have been
reverted to set their property directly (as was done before
v5.2.0). This avoids inheritance issues across nested elements,
including tables.
Added new .border-black
utility to match our
.text-black
and .bg-black
utilities.
Deprecated
Deprecated the .text-muted
utility and
$text-muted
Sass variable. It’s been replaced by
.text-body-secondary
and
$body-secondary-color
.
While not an exhaustive list, here’s some of the stuff we’re going to be working on before calling this release stable. You can track these and more in the v5.3.0-stable project on GitHub.
Up next will be the stable release of v5.3.0. Originally this was planned as a beta, but I think we’re getting close enough to call this final with one more release.
Head to https://getbootstrap.com for the latest. It’s also been pushed to npm:
npm i This email address is being protected from spambots. You need JavaScript enabled to view it.
Read the GitHub v5.3.0-alpha2 changelog for a complete list of changes in this release.
Visit our Open Collective page or our team members’ GitHub profiles to help support the maintainers contributing to Bootstrap.
Read more https://blog.getbootstrap.com/2023/03/24/bootstrap-5-3-0-alpha2/
Progressive Web Apps deliver a native mobile app-like experience using web capabilities. While oftentimes they’re an afterthought in a team’s mobile development strategy, they can be extremely useful tools for reducing development costs while still providing a top-tier user experience.
Think they’re outdated? Think again. Apple’s recently released iOS 16.4 beta 1 includes Web Push for Home Screen Web Apps. The Web Push API is based on the W3C standard and uses the same services as native apps, meaning that your notifications will be handled the same way as apps downloaded from the app store.
But how can you take them a step further? With Capacitor, Ionic’s open-source powerhouse, you can simplify the process of creating PWAs and using available Web APIs to turn them into native apps for app store distribution.
Progressive Web Apps, called PWAs for short, are web apps built using HTML/CSS/JavaScript that offer a native-like app experience, running seamlessly on a device’s browser. These apps are highly capable (with capabilities only growing thanks to new and modern APIs) and fast and dependable, regardless of network-connectivity. Installed PWAs run in a standalone window instead of a browser tab, so they’re launchable from the user’s home screen, dock, taskbar, or shelf. Users can search for them on their device, jump between multiple PWAs, so these handy web apps truly feel like part of the device they’re installed on.
Why should you care? Because PWAs also have massive potential business benefits.
First, PWAs are fast. With a <1 second median load time, they’re 4x faster with 10x less data than traditional apps. Second, they’re cost effective. If you already have a web app, there aren’t many extra steps needed to turn it into a PWA, which means no additional spend on development, new team members, etc. Third, they’re an SEO goldmine. PWAs take into account your organization’s SEO rankings, which come into play when users try to search for your app.
Plenty of well-known businesses are leveraging PWAs to better engage users. After switching to a PWA, Twitter saw a 65% increase in pages per session, 75% more Tweets, and a 20% decrease in bounce rate, all while reducing the size of their app by over 97%. Streaming giant Hulu created a PWA in lieu of their desktop experience and saw return visits increase 27% (Web.dev).
PWAs are easy and inexpensive to build, yet they’re fast and extremely reliable. Meanwhile, they’re great for search engine discoverability and can have massive business benefits. So why wouldn’t you build one?
As with anything, PWAs come with risks. One of the main risks is that the install process isn’t as simple as downloading an app from the app store. Users need to actually add PWAs to their home screen in order to access them easily. Android supports install banners, and the process to add to the home screen is fairly simple (Menu > Install App). On iOS, the process is a bit more cumbersome (Share > Add to Home Screen > Add).
Another risk is that you can build the perfect PWA, and users simply won’t find it. Users are trained to look for apps in the app store as opposed to on the web. That means that if a team wants their app to have the widest reach, they’ll need to consider getting it into an app store. Currently, the Apple App Store doesn’t accept listings of PWAs, but Google Play does. Apple’s recent beta release suggests there may be support for PWAs in the app store in the future, but the future remains unclear.
The offline experience of a PWA is also more limited than the offline experience of a native application, and devs need to consider the limitations of available web APIs. APIs don’t exist for every device-like functionality, so you run the risk of creating an inconsistent experience, especially since Web APIs are supported individually by browsers. That means that even if you build the perfect experience on Chrome, it may work entirely differently on Firefox or Safari. This also means that development teams often need to limit the features and functionality of their PWAs to ensure that they’re compatible across all web browsers.
While PWAs have their risks, using Capacitor can help mitigate them. Because Capacitor allows you to reuse your web apps across multiple platforms, it supports Progressive Web Apps and deploying to the iOS and Android app stores with minimal work on your end.
By distributing your web app as a native app, you can solve the issue of discoverability. By deploying both PWAs and traditional native mobile apps, you can meet your audience where they are and maximize your reach. Win/win!
With top tier support for both web apps and native apps, Capacitor’s cross-platform runtime solution supports running in either a native context or in the web, with many plugins available in both contexts using the exact same API and calling conventions. This offers both a smoother developer experience and a viable path forward for development teams to offer their application on every platform their users prefer.
In addition to a smoother developer experience, Capacitor lets development teams create a better experience for users as well. Capacitor also supports the use of PWA Elements, which offers an improved web-UI experience for Capacitor apps running in a browser as a PWA. Pre-built UI experiences for web APIs such as camera/video enables developers to create PWAs that meet and exceed native mobile experiences.
Progressive Web Apps are fast, reliable ways to connect with users. When executed properly, they can have huge business impacts, empowering teams to drive better results while lowering costs and overhead. However, they come with risks, and often have less features than native apps.
When you build with Capacitor, you get the best of both worlds – a Progressive Web App and a native app, without having to do redundant work. Capacitor’s APIs enable developers to build a better PWA experience for users and puts them on the path to creating a native app simultaneously. This enables development teams to push beyond PWAs and use their existing codebase to build and ship their apps to all popular distribution channels.
Learn more about Capacitor and try it for
yourself.
The post Take Your Web App Further with Capacitor appeared first on Ionic Blog.
Read more https://ionic.io/blog/take-your-web-app-further-with-capacitor