DEV Community: Adi Mizrahi

Application Loading Speed Impact

Adi Mizrahi — Tue, 28 Feb 2023 16:02:51 +0000

Background

We all want to make the most impactful native application we can, we want to build rich, visual, successful applications!

We try to consider everything: what is the goal/purpose of the application, the design, architecture, colors theme, dark mode support, does it require authentication, supported devices, and more…

There’s one area where we lack initial thought, and we do not always put our finger on it and understand its importance.

How fast our application loads, from the moment the user clicks the application icon till the moment he gets the first visual screen, the amount of time a user has to wait is crucial and important to the success of the application.

It’s important to note that users tend to have high expectations for app performance, and a slow-loading app can lead to poor user engagement and retention. As a result, it’s important for developers to optimize their apps for speed and ensure that they launch as quickly as possible.

The Reason

I want to start off with the why, and why applications load slowly. what are the main reasons that might cause an app to take a long time to interact with the user?

Large app size: If the app size is too large, it can take a long time for the application to download and install on the user’s device. This can significantly slow down the launch time. Poor network conditions: If the device is connected to a slow or congested network, it can impact the time it takes for data and assets to be downloaded, leading to a slow app launch.
Resource-intensive operations: If the app performs resource-intensive operations during launch, such as loading large amounts of data from the network or parsing complex data structures, this can slow down the launch time. Unoptimized code: If the app’s code is not optimized for performance, it can take longer for the app to launch. This may include inefficient algorithms, excessive use of memory, or poorly optimized graphics.
Background processes: If the device is running multiple background processes, this can reduce the available resources for the app and slow down its launch time. Outdated hardware: If the device is running on outdated hardware, it may not have the processing power or memory required to launch the app quickly.
Third-party libraries: If the app relies on third-party libraries, the time it takes to load those libraries can significantly impact the launch time. It’s important to ensure that the libraries are up-to-date and optimized for performance.

Impacts of Slow-Loading Applications

We’ve seen what might cause the application to load slowly, let’s talk about the impacts, what will be the impacts of a slow-loading application?

Poor user experience: A slow-loading app can lead to frustration and a poor overall user experience. Users expect apps to launch quickly and be responsive, and a slow-loading app can detract from their enjoyment of the app.
Decreased engagement: A slow-loading app may discourage users from using the app and reduce their overall engagement. Users may be less likely to use the app if it takes a long time to launch and is slow to respond to their inputs.
Decreased retention: A slow-loading app can lead to decreased user retention over time. Users are more likely to uninstall an app that takes a long time to launch and is slow to respond.
Decreased conversions: For e-commerce apps, slow loading times can lead to decreased conversions as users may abandon the app before completing a purchase.
Negative reviews: Slow-loading apps can lead to negative reviews and ratings in app stores, which can impact the app’s visibility and success.

Numbers

We’ve seen the impact, let’s talk numbers and percentages, how much will it hurt our application if it loads slowly?

User engagement: Research has shown that a 1-second delay in app load time can lead to a 7% reduction in user engagement.
User retention: A study found that a 1-second delay in app load time can lead to a 16% decrease in user satisfaction and a 4.1% decrease in daily active users.
Conversions: Slow app load times can also impact conversions, with research showing that a 1-second delay in app load time can lead to an 11% reduction in conversions.
Negative reviews: Slow-loading apps are more likely to receive negative reviews and ratings, with research suggesting that users are up to 3 times more likely to leave a negative review for an app that takes more than 3 seconds to launch.

Conclusion

In this article we showed why is loading speed of an application is so important, why showed the reason we want to improve and optimize our application load time, the impact a slow loading application can cause, and the numbers the “What’s in it for me?”

When designing an application be sure to take this factor into consideration as it’s an essential factor for your application’s success.

iOS (Swift) — Custom Transitions

Adi Mizrahi — Mon, 02 Jan 2023 18:45:28 +0000

While developing multiple apps through my years as an iOS developer, I was requested more than once to make a different custom transition between screens than what the iOS system default transitions have to offer.

In this article, I’ll show the basic transition the iOS system gives us, and how to create your own custom transition when moving between UIViewController.

Default transition

Imagine the following scenario, we have a button on the screen, when the user taps the button another screen with full-screen red background shows up.
The red background UIViewController will cover the current UIViewController from bottom to top, this is the default iOS transition and it’s called .coverVertical.

To present a UIViewController from another UIViewController we can use the following code:

let redViewController = UIStoryboard(name: "Main", bundle: nil)
                        .instantiateViewController(identifier: "redViewController")
redViewController.modalPresentationStyle = .fullScreen
self.present(redViewController, animated: true)

As mention before let us see all the transitions options the iOS system give us:

.coverVertical — this is the default behavior the iOS system gives us, the presented UIViewController covers the presenting UIViewController from bottom to top.
.flipHorizontal — flips the presenting UIViewController horizontally and presenting the new UIViewController on the other side.
.crossDissolve — fades the presenting UIViewController to the presented UIViewController.
.partialCurl — flips the presenting UIViewController to the presented UIViewController from bottom to top like a page in a book. An example of how to use a different iOS default transition than coverVertical:

func openRedViewController() {
  let redViewController = UIStoryboard(name: "Main", bundle: nil)
                          .instantiateViewController(identifier: "redViewController")
  redViewController.modalPresentationStyle = .fullScreen
  redViewController.modalTransitionStyle = .partialCurl
  self.present(redViewController, animated: true)
}

We’ve added the .modalTransitionStyle to our UIViewController and set its property to .partialCurl, so now we don't get coverVertical transition but paritalCurl instead.

Those four transitions are the basic transitions the iOS system gives us, but what if we wanted more? What if we want a different transition? What if we want to control the velocity, timing, alignment, and more? How can we do that?

The following code shows us how to create a “push” transition from right to left:

func createPushRightToLeftTransition() -> CATransition {
  let transition: CATransition = CATransition()
  transition.startProgress = 0.0
  transition.endProgress = 1.0
  transition.type = .push
  transition.subtype = .fromRight
  transition.duration = 0.3
  return transition
}

Firstly we create an object of type CATransition this object will contain all the properties we need to achieve the transition we want:

startProgress — Indicates the start point of the receiver as a fraction of the entire transition. endProgress — Indicates the endpoint of the receiver as a fraction of the entire transition.
type — the name of the transition, multiple options we have here: fade, moveIn, push and reveal. Defaultisfade`.
subtype — An optional subtype for the transition. used to specify the transition direction for motion-based transitions, values: fromLeft, fromRight, fromTop, fromBottom.
duration — The basic duration of the transition. (seconds) We just created our transition object, but how do we use it? Let’s take a look at the following code:

`
func openRedViewController() {
let redViewController = UIStoryboard(name: "Main", bundle: nil)
.instantiateViewController(identifier: "redViewController")
let transition = createPushRightToLeftTransition()
self.view.window?.layer.add(transition, forKey: "kCATransition")
self.present(redViewController, animated: false)
}



Again, as we have seen before we are creating our `redViewController` object, but there are two main changes here so we can use our custom transition.

- We added a new line, on the view.window` where we add to its layer our custom transition.
when we call `self.present` we have to set the animated parameter to false.
- Those two conditions will allow us to use our custom transition, once we call this function the `redViewController` will be pushed from right to left in 0.3 seconds.

Let’s see another example of a custom transition, this time we are going to create a fade transition, where the presenting `UIViewController` fade out and the presented `UIViewController` fades in:

func createFadeTransition() -> CATransition {
let transition: CATransition = CATransition()
transition.type = .fade
transition.duration = 0.75
return transition
}

As we did before, we create our `CATransition` object, but this time we use fade as our type for the transition, we then set the duration to 0.75 seconds.

As same as we did before with presenting a `UIViewController` with a custom transition, we can do the same when want to dismiss a `UIViewController`, take a look at the following code snippet:

func dismissViewController() {
let transition = createFadeTransition()
self.view.window?.layer.add(transition, forKey: "kCATransition")
self.dismiss(animated: false, completion: nil)
}



Important to remember here is to set the animated property for the dismiss function to false otherwise, our custom transition will not work.

## Conclusion
CATransition object is great to create different and custom transitions. we have a variety of types and subtypes with can use to create many custom transitions, we can also set the duration of the transition, the start point, and the endpoint.
For more reading about custom transitions please click [here](https://developer.apple.com/documentation/quartzcore/catransition).

Cloudinary with Android

Adi Mizrahi — Fri, 23 Dec 2022 20:31:04 +0000

For years I’ve been an Android developer, and only in recent months have I gotten to dive back into the Android world (after years of iOS development).

As I mentioned in my previous iOS post a few months ago I joined a great company Cloudinary and that’s what I’ll write about today.

The Problem

In one of my previous jobs, I was responsible for an application that allows you as the user to download images into your phone and set them as a background for the home screen, lock screen, or both.
This application requires pulling big JSON files with all the image information, each image having multiple fields such as title, URL, created date, etc…
On the main screen, I had to present a thumbnail (A thumbnail is a small image representation of a larger image) of each image.
Tapping a thumbnail will direct the user to a screen where the image is shown full screen.
These 2 screens already required multiple versions of the same image. Since you can’t present a full-screen image with a thumbnail image because you’ll get a pixelated result which yields a bad user experience. On the other hand, We don’t want to present the full-screen image on the main screen (where we show many images on a screen) because it’ll cause a long load time of the screen. Which is again a bad user experience.

Other than that, each image has various sizes that we need to present, and let us not forget that the application supports multiple devices with different screen sizes, many manufacturers, phones, tablets, etc… which require different sizes of the image.
So how can we handle this? We have one image, but we need it in many different sizes. We can take it on the client side and manipulate the image on the device but that won't be efficient.
We can ask our server side (if we have one) to give us multiple URLs for each image but that will make the JSON response huge and hard to handle.

This is where Cloudinary comes in.

The Solution!

As you might have guessed the solution will be Cloudinary
What is Cloudinary?
Cloudinary is a platform that allows you to quickly and easily create, manage and deliver digital experiences across any browser, device, and bandwidth.

How to use Cloudinary?

Setup
The first thing you need to do is go to the Cloudinary website and sign-up for a free account.

You can find the git repository for the Android SDK here.
To integrate Cloudinary into your app you can use:

//Gradle
implementation 'com.cloudinary:cloudinary-android:2.2.0'
//Maven
<dependency>
    <groupId>com.cloudinary</groupId>
    <artifactId>cloudinary-android</artifactId>
    <version>2.2.0</version>
</dependency>

Configuration
Once the package is integrated, we’ll need to set up our Cloudinary object.
Your API-Key and Cloud-Name will appear in the dashboard where you created your account.

Now that we have our Cloudinary object set and ready to use that’s where the MAGIC starts.

Upload your assets
There are multiple ways to upload an asset to your cloud, via the API or the UI
UI —It’s as simple as dragging and dropping into your cloud.
API — You can upload through the code:

String requestId = MediaManager.get().upload(imageFile).unsigned("sample_preset").callback(callback).dispatch();

The only thing we’re missing here is the upload preset. An upload preset is a field we need to set through the UI. You can do this by going to the Cloudinary website, signing in, and clicking the settings icon at the top right. Click the upload option, scroll down and add a new upload preset, There are many options to customize an upload preset but I’m not going to dive into them in this blog. Check out the Cloudinary Academy to learn more about what’s possible with Cloudinary’s APIs.

Once the upload preset is created, be sure to put its name in the upload preset field in the unsigned function.
Yes, that simple to upload an asset to your cloud, once the image is there we can start using transformations!
Transformations are manipulations we can perform on an asset (image, video, etc…) there are many transformations and if you want to learn more than the examples I show here I suggest visiting Cloudinary’s documentation.

Transformations
At the start of this article, I presented the problem where we have one asset, but we need it in many different sizes and aspect ratios. Let’s see how we can achieve that very easily using Cloudinary’s transformations: (I’m going to use an asset called sample)

The original image:

Crop
We want to create a thumbnail(250x250) for our main screen:

String url = MediaManager.get().url()
  .transformation(new Transformation()
  .crop("crop").width(250)
  .height(250))
.generate("big_image_sample");

Let me explain the code line above. We’re using the MediaManager object we created before, we call the url() function and setting a new transformation where we give all the parameters we want to modify in the image, lastly we call generate with the asset name (sample).
This line of code will produce the following URL:

As we can see we got the 250x250 thumbnail we wanted, but the result could be improved. The “bee” which is the most interesting object in the image is cut off. What can we do? OH! Cloudinary has a few more tricks up its sleeve! Another COOL feature we can use “gravity” where we can ask Cloudinary to focus on the most interesting object in the image.

Gravity

String url = MediaManager.get().url()
  .transformation(new Transformation()
  .crop("crop").width(250).height(250).gravity("auto"))
.generate("big_image_sample");

The output URL:

And as we can see the result is much better. The focus is on the bee.

Quality
Let’s try another scenario. We have a 2k image, which is quite a large file, and we don’t need it in its best form when we’re presenting it on the device. Roaming can’t always handle big bandwidth. To make the image lighter we can use the Cloudinary “quality” feature.

Here’s the original image (it weighs 5MB which is quite a large file)

With Cloudinary we can do the following:

String url = MediaManager.get().url()
.transformation(new Transformation()
  .quality("auto"))
.generate("big_image_sample");

This code will produce the following URL:

And it weighs 626.56 KB. So we reduced the size by a lot, and it’ll be easier to get this image on a mobile device.

To sum up!

As we saw in the blog, Cloudinary can answer the requirement to handle the same asset in many sizes and qualities. Not only that it has many other features! I encourage you to visit the documentation website to get the best out of the platform.

The Cloudinary SDK can also be found on iOS and 14 more languages you can find at Cloudinary’s git.

Cloudinary with Swift(iOS)

Adi Mizrahi — Fri, 23 Dec 2022 20:23:09 +0000

Hi! Adi here. Been a while since I wrote. Switched jobs a few months ago, and it took most of my capacity, so I wasn't able to write. I’ve joined a great company called Cloudinary, and it is part of the reason I’m writing this blog. So let’s get started.

The Problem!

In one of my previous jobs, I was responsible for an application that allows you as the user to download images into their phone and set them as a background for the home screen, lock screen, or both.
This application requires pulling big JSON files with all the image information, each image having multiple fields such as title, URL, created date, etc…

On the main screen, I had to present a thumbnail (A thumbnail is a small image representation of a larger image) of each image.
Tapping a thumbnail will direct the user to a screen where the image is shown full screen.

These 2 screens already required multiple versions of the same image. Since you can't present a full-screen image with a thumbnail image because you’ll get a pixelated result which yields a bad user experience. On the other hand, We don't want to present the full-screen image on the main screen (where we show many images on a screen) because it’ll cause a long load time of the screen. Which is again a bad user experience.

Other than that, each image has various sizes that we need to present, and let us not forget that the application supports multiple devices with different screen sizes, iPhones, iPads, and iPods which require different sizes of the image.

So how can we handle this? We have one image, but we need it in many different sizes. We can take it on the client side and manipulate the image on the device but that won't be efficient.

We can ask our server-side (if we have one) to give us multiple URLs for each image but that will make the JSON response huge and hard to handle.

This is where Cloudinary comes in.

The Solution!

As you might have guessed the solution will be Cloudinary

What is Cloudinary?
Cloudinary is a platform that allows you to quickly and easily create, manage and deliver digital experiences across any browser, device, and bandwidth.

How to use Cloudinary?

Setup
The first thing you’ll need to do is go to the Cloudinary website and sign-up for a free account. You can find the git repository for the iOS SDK here. To integrate Cloudinary into your app you can use:

CocoaPods:

pod 'Cloudinary', '~> 3.0'

Carthage:

github "cloudinary/cloudinary_ios" ~> 3.0

Swift package manager:

https://github.com/cloudinary/cloudinary_ios.git

Configuration
Once the package is integrated, we’ll need to set up our Cloudinary object.
Your API-Key and Cloud-Name will appear in the dashboard where you created your account.

//Create the configuration object
let config = CLDConfiguration(cloudName: "CLOUD_NAME", apiKey: "API_KEY")
//Next we create the Cloudinary object
let cloudinary = CLDCloudinary(configuration: config)
view raw

Once we have our Cloudinary object set and ready to use, this is where the MAGIC starts.

Upload your assets
There are multiple ways to upload an asset to your cloud, via the API or the UI
UI — it’s as simple as dragging and dropping into your cloud.
API — You can upload through the code:

let request = cloudinary
.createUploader()
.upload(url: file, uploadPreset: "sample_preset", params: CLDUploadRequestParams())
.response({
    (response, error) in
    // Handle response
})

Once the upload preset is created, be sure to put its name in the upload preset field in the uploadfunction. Yes, it’s as simple as that to upload an asset to your cloud, once the image is there we can start using transformations!
Transformations are manipulations we can perform on an asset (image, video, etc…) there are many transformations and if you want to learn more than the examples I show here I suggest visiting Cloudinary’s documentation.

The original image:

Crop
We want to create a thumbnail(250x250) for our main screen:

let url = cloudinary.createUrl().setTransformation(
  CLDTransformation().setWidth(250).setHeight(250).setCrop(.crop))
.generate("sample")

Let me explain the code line above. We’re using the cloudinary object we created before, we call the createUrl() function and set a new transformation where we give all the parameters we want to modify in the image. Lastly, we call generate with the asset name (sample).
This line of code will produce the following URL:

Gravity

let url = cloudinary.createUrl().setTransformation(
  CLDTransformation().setWidth(250).setHeight(250).setCrop(.crop).setGravity(.auto))
.generate("sample")

The output URL:

And as we can see the result is much better. The focus is on the bee.

Quality
Let’s try another scenario. We have a 2k image, which is quite a large file, and we don't need it in its best form when we’re presenting it on the device. Roaming can’t always handle big bandwidth. To make the image lighter we can use the Cloudinary “quality” feature.

Here’s the original image (it weighs 5MB which is quite a large file)

With Cloudinary we can do the following:

let url = cloudinary.createUrl().setTransformation(
  CLDTransformation().setQuality(.auto()))
.generate("big_image_sample")

This code will produce the following URL:

And it weighs 626.56 KB. We reduced the size by a lot, and it’ll be easier to get this image on a mobile device.

To sum up!

The Cloudinary SDK can also be found on Android and 14 more languages you can find at Cloudinary’s git.

The best image format for mobile app

Adi Mizrahi — Fri, 23 Dec 2022 20:10:49 +0000

Throughout the years of app development (on both iOS and Android platforms), I ran into the same problem, what format should I use, what would be the optimal format for this OS (Android or iOS), that OS version, and the hardware that the device has, can it run what I’m building performance wise?
I decided to write about this issue. In the following text, I will describe the various formats and how and when we could use them.

iOS

iOS 11+ — Since iOS 11, Apple has introduced a new iPhone photo format, HEIC format for iOS devices. HEIC is more efficient when it comes to file size while keeping the same image quality compared to JPG.

iOS 10 — Before iOS 11 the recommended image format was PNG.

HEIC vs PNG

The new file format HEIC stores images with smaller file sizes when you compare them to the common image file format i.e., PNG.

Even though the size of the HEIC image is smaller than the PNG image file, the image quality is similar to the PNG format.

Compared to the PNG file, the HEIC file is far more flexible as it can store a single image or sequence of images. While on the other hand, the PNG file can hold only one image.

In addition to it, the HEIC file contains an image, along with its metadata.

HEIC vs JPEG

Compression
HEIC offers a much more efficient, modern compression method than the older JPEG format. HEIC breaks images into significantly smaller files without affecting quality.

Storage space
Most HEIC files will take up significantly less room than JPEG on a computer, tablet, or smartphone.
Their innovative compression process means HEIC can use as little as half the space that a JPEG file would.

Image quality
When it comes to both compression and image quality, HEIC files win out over JPEG. The HEIC format can enhance the quality of photos with transparency and broader dynamic range capabilities.

Compatibility
While JPEG has almost universal compatibility, HEIC files don't. HEIC has become more commonplace in recent years, but its primary use is on Apple devices. You may even need to convert your HEIC files to JPEG when transferring photos from an iPhone to a PC.

Transparency
HEIC supports image transparency in a similar way to PNG files, on the other hand, the JPEG format doesn't support transparency.

Extra Note

But that’s not the end of it, on older devices that still support iOS 11 (iPhone 6 for example) HEIC might still work but due to slow hardware, it might take a long time to render a HEIC format image.
This means that the iOS version is not the only parameter to determine the image format, it should also come from the device itself.

Android

Android 4.2.1- — The recommended image format for the older Android version is PNG

Android 4.2.1 (API level 17)+ — Support for webp was added.

Android 12+ — Support for AVIF was added on Android 12+.

WebP vs PNG

This format provides superior lossless and lossy compression for images. Using webp, developers can create smaller, richer images. webp lossless image files are, on average, 26% smaller than PNG. These image files also support transparency (also known as alpha channel) at a cost of just 22% more bytes.
webp as a format can support both lossy and lossless modes, making it an ideal replacement for both PNG and JPG. The only thing to keep in mind is that it only has native support on devices running Android 4.2.1 (API level 17) and higher. Fortunately, most devices satisfy that requirement.

WebP vs JPEG

According to this study, we see that the average webp file size is 25%-34% smaller compared to JPEG files, there results of the study indicate that webp can provide significant compression improvements over JPEG.

Background

AVIF is a container format for images and sequences of images encoded using AV1. AVIF takes advantage of the intra-frame encoded content from video compression. This dramatically improves image quality for the same file size when compared to older image formats, such as JPEG or PNG.

AVIF vs PNG

As a lossless compression file format, PNG images are notorious for their large file sizes. AVIF supports both lossy and lossless compression. It is this versatility that gives AVIF an edge when it comes to file size.

Decoding a PNG is instant, thanks to the lack of complexity, AVIF tend to be more complex, therefore slower systems may struggle a bit more to decode the image.

Currently, PNG still holds is the best format for lossless compression with reduced file sizes and greater platform support. AVIF is an excellent alternative for delivery if you’re willing to turn to lossy compression to reduce the file size, but comes with complexity that older platforms with old hardware may find challenging to render.

AVIF vs JPEG

Quality
JPEG suffers in terms of compression quality today. Indeed, even the more modern JPEG 2000 can offer better overall compression.
On the other hand AVIF tends to provide some of the best results we can achieve with lossy, non-photographic images.
Those who are dealing with an image with low fidelity AVIF will out-perform JPEG . But there are cons AVIF as well, AVIF image does not support progressive rendering, so files must be downloaded entirely before they can be displayed.

Speed comparison
JPEG is outdated and was written before the invention of multicore CPU chips. It is not designed to work with a sequential process where there are multiple cores.
AVIF can work in parallel with multiple cores which makes it a more suitable form of image compression.

Animation
JPEG is an image format. This means that it was designed to show still images.
AVIF is based on an actual video codec and provides animation capacity which means it can support animations and JPEG cannot.

Overall
Even though JPEG 2000 was a substantial improvement from the original JPEG format it still cannot compete with AVIF in many ways:
AVIF has become the ideal choice for those who need to manage encoding in a low-bandwidth setting, even though JPEG supports progressive rendering it still lacks a lot of features that AVIF offers.

Extra note
Some devices with slow/old hardware might be able to get AVIF or webp based on their Android version but their hardware may fail to render those formats (due to low memory) or it could take a long time (due to a slow processor/ graphics processor).
Same as iOS the Android optimal format can’t only be determined based on the Android version but we’ll have to consider the Android device as well.

Older Versions Format

PNG vs JPEG

I want to raise another point here, for the older versions I did state that PNG will be the optimal image format, but that’s not always true, PNG vs JPEG decision should be based on the complexity of the image and not solely on the platform they are running on.
For example:

The image above shows two images that come out quite differently depending on which compression scheme the developer applies. The image on the left has many small details, and thus compresses more efficiently with JPG. The image on the right, with runs of the same color, compresses more efficiently with PNG.

How to choose a format for Android?

The following image provides a simple visualization to help you decide which compression scheme to use, one thing that should come into account, if the device supports Android 12+ you should consider (based on the restrictions I described here) using AVIF.

How to choose a format for iOS?

Taking into account the restrictions I mentioned before, the decision should be pretty easy, iOS 11+ should always use HEIC lower iOS version should go for PNG.

Conclusion

Choosing an image format is no easy task, you must take into account a lot of parameters such as OS version, device, and image complexity.
We can always choose the easy path and set JPG to everything, but if we want better performance, better loading time, and overall better user experience we need to pick the correct format for each use-case.

For further reading you can click the links below:
HEIC
AVIF
WebP

Xcode 14, It’s improving!

Adi Mizrahi — Fri, 23 Dec 2022 19:57:26 +0000

On the 12th of September Apple released the new Xcode version, Xcode 14.
In this article, we’re going to discuss the changes and improvements that Apple put into its IDE.

Size matters

Apple reduced the size of Xcode, compared to Xcode 13, Xcode 14 is 30% lighter.
Xcode 13.4.1 weighs 10GB while Xcode 14.0 is 7.0GB, this is a big change since there were a lot of complaints from developers regarding Xcode size.

Improved Auto-Completion

An IDE that autocompletes when typing code is a great developer experience and a necessity for every developer.
Xcode 14 is a great improvement from Xcode 13 when it comes to code completion.

For example, Xcode will autocomplete a whole init function for you when you defined the class and the class members:

But that’s not the only new feature, this works also for objects that conform Codable protocol, when you define the init function the Xcode will suggest completing init(from decoder: Decoder) {…} and will automatically autocomplete the entire function for you as you can see in the example below:

And the result will be:

You can notice I also added the encode function, if you start typing encode Xcode will also autocomplete the entire function for you.

Asset Catalog

There are also improvements when it comes to the asset catalog, no more various app icon sizes, in Xcode 14 there is only 1024x1024:

You can now double-click an image from the asset catalog to go to the file.

You can also paste images directly from the clipboard to the asset catalog.

Improved Build Time

More improvements are coming with the new Xcode version, this time it’ll save even more time.

Build times have been improved significantly, with better parallelism algorithms that improved speed by x2, and projects' build time is 25% faster overall.
The more cores you have on your Mac, the greater the improvement you’ll be seeing, Testing on the M1 Ultra studio showed an improvement of 30% in build time.

And that’s not all, document loading improved by 50%, notarizing is 4x faster if you use the Interface Builder, and swapping between iPads and iPhones from the device bar is now 30% faster.

Stronger and faster “Xcode Previews”

When SwiftUI was introduced one of its key features was the “Xcode Previews”, this feature helps developers see all the UI changes in real-time side by side with the code.
This means developers don't need to context switch, go back and forward to the UI, run the application on a simulator just to see what changed, and have a better development experience.
The big change that Xcode 14 brings in is an interactive preview canvas, this means a developer can interact with the canvas (click a button, go between screens, etc).
Xcode 14 comes with whole new specific controls that help the developer view the same UI in different orientations, schemes, or even dark mode, you can even see the same UI with different font sizes up to 12 screens at the same time.

Build Timeline

In the previous versions of Xcode, we could only see build logs as one big list without much information about the steps, with Xcode 14 you can see exactly how much time each step took, and we can see a full timeline.

Simulator

Xcode 14 also improved the simulator, it now supports remote notifications with iOS 16 simulators running on macOS 13 with Apple Silicon or T2 processors.

With that said, the simulator will only support Apple Push Notification within the Sandbox environment.
The APNS tokens will be a unique combination of both the Mac hardware and the simulator.

Summarize

Xcode 14 comes with various new features and improvements, faster coding (due to autocompletion), faster build time, improve simulator usage, and overall a better developer experience.

If you would like to read the full release notes you can find them here.

Cloudinary with Flutter

Adi Mizrahi — Thu, 22 Dec 2022 18:36:39 +0000

As of late I've begun exploring different avenues regarding Google's Flutter framework.
For the people who don't have the foggiest idea, Flutter is a cross-stage platform framework (Same as React Native) based on Dart programing language.

After playing with the framework and understanding the best practices (thank you Effective Dart), I started to build our (Cloudinary’s) Flutter SDK.

In the following article, I’ll explain why we decided to implement this SDK, how you can use it, and what good it will do for your application.

The problem

One of the biggest pain points for a mobile developer is dealing with performance issues caused by handling many assets (images, videos, etc.) on multiple devices with different size screens.

In one of my previous jobs, I was responsible for an application that allowed users to download images into their phones and set them as backgrounds for the home screen, lock screen, or both.
This application required pulling big JSON files with all the image information, including multiple fields such as title, URL, created date, etc…
On the main screen, I had to present a thumbnail (a small image representation of a larger image) of each image.
Tapping a thumbnail would direct the user to a screen where the image was shown full screen.
These 2 screens already required multiple versions of the same image. You can’t present a full-screen image as a thumbnail image because you’ll get a pixelated result which yields a bad user experience. On the other hand, we didn't want to present the full-screen image because that would cause a long load time for the screen, which is again a bad user experience.

Moreover, every image came in a different size, so we had to find a way to present them uniformly.
To add to the complexity, we wanted this app to work with different screen sizes (iPhones, iPads, different Android devices, and Android base tablets) which require different image sizes.
The scenario in which we have a single image that needs to be displayed in many different sizes is very common. How can we best handle it? Let’s go through some possibilities.

One solution would be to get it in one size for the client and manipulate it for our needs. Unfortunately, this solution wouldn't be efficient and could cause a long processing time.
We could handle it on the server side (if we have one). We could create multiple URLs and send them to the client. But that would create big JSONS would be harder to handle and parse.

That’s where Cloudinary comes in.

The solution

What’s Cloudinary?
Cloudinary is a platform that allows you to quickly and easily create, manage and deliver digital experiences across any browser, device, and bandwidth.

Working with Cloudinary

Setup

The first thing you need to do is go to the Cloudinary website and sign-up for a free account.

You can find the Git repository for the Cloudinary Flutter SDK here.

To integrate Cloudinary into your app you can use:

  cloudinary_flutter: ^0.0.1
  cloudinary_dart: ^0.0.7

Configuration

Once the package is integrated, we’ll need to set up our Cloudinary object.
Your cloud name will appear in the dashboard where you created your account.

CloudinaryContext.cloudinary = Cloudinary.fromCloudName(cloudName: '<Cloud_name>');

Now that you have your Cloudinary object set and ready to use, the MAGIC starts.

Transformations

At the start of this article, I presented the problem where we have one asset, but we need it in many different sizes and aspect ratios. Let’s see how we can achieve that very easily by applying Cloudinary’s transformations.

Here’s the original image called ‘dog’:

Crop

You can easily create a thumbnail(500x500) for your main screen:

String url = (CloudinaryContext.cloudinary.image('dog')
            ..transformation(Transformation()
              ..resize(Resize.crop()
                ..width(500)
                ..height(500))))
          .toString();

This code creates a new string URL using the Cloudinary object that was initiated in the previous step. The image function builds the URL using the publicId of the specified image.
When calling transformation you can specify the action you want to perform. In this case, the resizeaction is applied with the Crop and the values for width and height , Finally, the toString()turns the object into a string.

This code will output a URL for the following image:

As we can see we got the 500x500 thumbnail we wanted, but the result could be improved. We lost the dog and we can only see white fur (not optimal at all).
What can we do? OH! Cloudinary has a few more tricks up its sleeve! Another COOL feature we can use is “gravity” where we can ask Cloudinary to focus on the most interesting object in the image.

Gravity

String url = (CloudinaryContext.cloudinary.image('dog')
            ..transformation(Transformation()
              ..resize(Resize.crop()
                ..width(500)
                ..height(500)
                ..gravity(Gravity.autoGravity()))))
          .toString();

And as we can see the result is much better. The focus is on the dog’s face.

Quality

Let’s try another scenario. You want to deliver a 2k resolution image, which is quite a large file, and you don’t need to present it in its best form. Roaming can’t always handle big bandwidth. To make the image lighter we can use the Cloudinary “quality” feature.

Here’s the original image (5MB)

With Cloudinary we can do the following:

String url = (CloudinaryContext.cloudinary.image('dog')
             ..transformation(Transformation()
             ..delivery(Delivery.quality(Quality.auto))))
             .toString();

This code will produce the following URL:

After this transformation, the size is reduced to 626.56 KB and it’ll be faster to load this image on a mobile device.

Cloudinary’s Image Widget
So far we’ve seen how to generate URLs and we can manually put them into an image widget, but Cloudinary gives us an extra zing, an image widget that can integrate with everything we’ve implemented so far.

CldImageWidget(
        publicId: 'dog',
        transformation: Transformation()
           ..resize(Resize.crop()
               ..width(500)
               ..height(500)
               ..gravity(Gravity.autoGravity()))
           ..delivery(Delivery.quality(Quality.auto)),
             ),

In the code snippet above we see that we create the image widget and we give the following attributes:

Public Id
Resize crop, with width=500 and height=500 and Gravity auto
Delivery with quality auto
This code will generate the URLs we’ve seen before and will inject them into the image widget.

To sum up!

In this blog, you saw how Cloudinary can handle the same asset in many sizes and qualities. That’s just the tip of the iceberg. Cloudinary has many other features that you can use when managing the media in your apps.
I encourage you to visit Cloudinary’s documentation to get the most out of the platform.

The Cloudinary SDK can also be found on Android and iOS and 14 more languages you can find at Cloudinary’s git.