DEV Community: German

Light up your SwiftUI TabView

German — Mon, 27 Mar 2023 10:53:07 +0000

In SwiftUI, the TabView APIs and customization is somewhat limited. We can often see tutorials and articles on how to create custom tab view components replicating similar layouts and behaviors. This time I want to show you very simple explorations I did last night with the native TabView component that will add some sparks to your app.

The code is super simple, let's start with a basic TabView layout in SwiftUI within our main view's body.

var body: some View {
  TabView(selection: $selectedTab) {
        FirstScreen()
          .tabItem {
            Image(systemName: "1.circle.fill")
            Text("First tab")
          }
          .tag(RootTab.first)
        SecondScreen()
          .tabItem {
            Image(systemName: "2.circle.fill")
            Text("Second tab")
          }
          .tag(RootTab.second)
        ThirdScreen()
          .tabItem {
            Image(systemName: "3.circle.fill")
            Text("Third tab")
          }
          .tag(RootTab.third)
      }
      .background(Color.secondary)
      .tint(.red)
}

A couple of things here:

We are using the initializer of TabView that receives a Binding for the selected value. We will use it later also, but for now, we will declare a @State var in our host view:

@State private var selectedTab: RootTab = .second

This is how it looks the RootTab enum, but you can basically use you own typed tabs.

internal enum RootTab: Int {
  case first, second, third

  /// We use this to color the light of each tab when selected.
  var selectionColor: Color {
    switch self {
    case .first, .third:
      return .purple
    case .second:
      return .main
    }
  }
}

Now, this is the standard look and feel of the TabView, which doesn't bring that much joy :(

The idea is to add a light that focuses on the selected tab, and changes when the user switches to other tabs. For that, let's use an overlay modifier in out TabView like follows:

TabView() {...}
  .overlay(alignment: .bottom) {
        let color = selectedTab.selectionColor
        GeometryReader { geometry in
          let aThird = geometry.size.width / 3
          VStack {
            Spacer()
            Circle()
              .background(color.blur(radius: 20))
              .frame(width: aThird, height: 30)
              .shadow(color: color, radius: 40)
              .offset(
                x: CGFloat(selectedTab.rawValue) * aThird,
                y: 30
              )
          }
        }
      }
      .edgesIgnoringSafeArea(.bottom)

How does it work?

The overlay adds a Circle shape on top of our TabView.
We style the circle to have a shadow with big blur value that will simulate the light in the selected tab.
The background modifier doesn't really need to be a blurred color but it enhanced the light effect a bit. You can play around and see how it works for you.
We set the width of the Circle to third of the screen's width by using a GeometryReader to get the size of the TabView. The height is up to you but it changes the strength of the shadow so again, play around to get the best results.
Then we use an offset modifier to position the Circle shape, this allow us to position the shape itself below the TabView and letting only the shadow portion visible.
The horizontal offset(x axis), will be updated when the selectedTab changes, so the light moves when the user switches tabs.
Last, but no least, the edgesIgnoringSafeArea allows the overlay to ignore the safe area and go beyond the screen.

Then, we can add a simple Spring animation when the selectedTab value changes to give a better overall experience:
.animation(.spring(), value: selectedTab)

🎉 This is the final result:

It gets better on dark mode:

One thing to have in mind is that the overlay is on top of our TabView, as the name says, so we have to be careful not to cover our tab items if we add something more than a light.

That is it, simple and effective. I hope you enjoy the simplicity of SwiftUI like I do. 🚀

Cleaning your Xcode's garbage

German — Tue, 14 Mar 2023 22:22:29 +0000

Mobile devs out there with 128 or 256Gb SSDs Macbook: Hear me out!
If you find yourself struggling with the available free space on your disk, like Xcode not building or Terminal commands failing. All these happen because they can't write files to the SSD.
The good news are, I have a great solution for you:

Xcode-clean script
Shout out to Niklas Berglund

I found this script many years ago and I still use it, even when I am currently working on a 512Gb Macbook Pro.

Of course there are several less technical alternatives to do this, like cleaner apps, cache cleaning tools, etc.
But for some reason I tend to go with the nerdiest solutions.

For convenience you can create an alias like I did. Add the following line to your bash profile, oh-my-zsh, or whatever shell you use:

alias cleanxcode='~/xcode-clean.sh/./xcode-clean.sh'

Then, you can use it like:
> cleanxcode --help

Output:

Usage: /Users/.../xcode-clean.sh/./xcode-clean.sh [options]

Frees up disk space by removing Xcode data. NOTE: you might want to keep backups of the dSYM files in ~/Library/Developer/Xcode/Archives

EXAMPLE:
    /Users/.../xcode-clean.sh/./xcode-clean.sh -A

OPTIONS:
   -h           Show this help message
   -b [path]    Backup dSYM files to specified path before removing archives
   -a           Removed all Xcode archives
   -d           Remove everything in DerivedData folder
   -D           Remove everything in DeviceSupport folder
   -s           Remove simulator data
   -A           Remove all of the above(archived, DerivedData and simulator data)
   --dry-run    Dry run mode prints which directories would be cleared but don't remove any files

A common use case for me is:
> cleanxcode -a -d -s

It wiped out a total of 9Gb this time 👍🏻

Clearing archives in /Users/.../Library/Developer/Xcode/Archives/* (freeing 25M disk space)
Clearing DerivedData content in /Users/.../Library/Developer/Xcode/DerivedData/* (freeing 7.6G disk space)
Clearing simulator data in /Users/.../Library/Developer/CoreSimulator/Devices/* (freeing 1.4G disk space)

That is all for today.
I hope you find it as useful as I do.

How to Create a Live Streaming App

German — Tue, 14 Mar 2023 11:57:00 +0000

How to Create a Live Streaming App

Abstract: A few ideas and considerations for architecting a live streaming application based on our previous experience.

Live streaming

The term implies that the media(audio, video, or both) is broadcasted to the end-users in real-time. This is different than just streaming which could refer to previously recorded content such as VOD(Video On Demand), music streaming, etc. Streaming media is delivered and played on demand rather than being generated simultaneously.

This specific difference makes live streaming a lot harder to design, implement and scale.

Building a Live Streaming App

There are different approaches you can take to build your live streaming platform:

Implement your own.
Use one of the existing Platform as a Service (PaaS) solutions.
Use an existing software solution that you can run on your own Infrastructure as a Service (IaaS).

While the first option sounds complicated (it is), it might be the best choice if you have the time, resources, and super specific requirements for your live streaming app. Since I wouldn't recommend coding the entire streaming software from scratch; a good starting point would be the open source solutions.

Now, let's take a look at the pros and cons of options 2 and 3.
These are proven to be a great launch pad for startups and also more complex solutions.

PaaS

There are a few PaaS around that allow you to quickly build your streaming app and take some sort of control on specific aspects of the streaming process, the audience, etc.
The most popular are:

Pros: these platforms will take care of all the scalability, configuration, and infrastructure.

Cons: if your solution requires the live transmissions to start right away; these solutions won't work for you most of the time. The warm-up times are usually up to several minutes.

A simple architecture preview using one of the PaaS above would look like this:

These platforms are the best fit if you plan to broadcast scheduled live events. i.e: Sport events, concerts, TV Channels.

SaaS

The following media server software gives you all the capabilities required to live stream(ingest, transcode/transrate, output, etc).
Pros: These are very flexible and allow you to tweak almost every parameter of the streamflow, add custom behaviors, and integrate with third-party tools.

Cons: Contrary to the platforms, they don't provide any infrastructure and you will be in charge of the installation, configuration, and design along with putting all of this together in your cloud service. You are responsible for whether or not the solution scales.

Some of them provide software-based load balancers and other mechanisms that help you to ease all the work previously mentioned.

Without much details on scaling and other mechanisms, a live streaming platform architecture using a SaaS could look like this:

This approach requires more work and resources to get your final solution working properly, but the possibilities are endless.

Considerations

There are some questions that we must ask ourselves before thinking about a solution or anything else.

How critical is it to achieve the lowest latency possible?
Where will the end-users be watching live streams?
Should my platform support thousands or even millions of users?

The answers to these questions will set a starting point for your investigations, POCs and even technologies and tools to use.

Latency matters

This is one of the most important topics to analyze when architecting your solution, and you have basically two different scenarios.
Let's say your platform will be streaming TV shows on a schedule, where viewers aren't allowed to comment or anything.
In this particular scenario achieving low latencies is not necessary, and embracing a 15-30 seconds delay would be my recommended way to go.
HTTP Live Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH), and Microsoft Smooth Streaming are some of the technology standards designed to stream media content to clients. They all work over HTTP and in a very similar way, the media consists of a playlist of small chunks of data. The duration of the chunks, the number of chunks in each segment, amongst other things defines the theoretical delay mentioned above, making these standards worth considering for the current scenario.

Then we have the second scenario, where your platform will need support for user engagement and interaction during the live streaming, and the real-time factor is critical. The most common real-time features we see in today’s apps are chats, polls, reactions, and screen sharing/collaboration.
This requirement makes things more complex, specifically if we talk about scalability and synchronization.

Real Time Messaging Protocol (RTMP), Real Time Streaming Protocol (RTSP) and Web Real-Time Communication (WebRTC) are the best options out there when ultra low latency is in play.
They all support really low latencies, but the clear winner is WebRTC with its sub-second delay capabilities, closely followed by RSTP with just above 1 second delay. This is because WebRTC is based on UDP rather than TCP like RTMP does.
Of course there are more differences and technical factors to consider. Here is a short reading on those.

Live streaming Playback Feature

Live streaming apps often allow users to watch the content from their mobile devices, computers, laptops and smart TVs.
To support all these your streaming servers could transcode the original media into various streams to provide multiple playback formats.
You should consider that not all platforms support all playback formats, or at least not natively and that some of them are more problematic with certain formats.

Here are some of the facilities and obstacles you might face:

1. Mobile

HLS playback is natively supported in both, iOS and Android.
MPEG-DASH is not supported and a third party player is needed.
RTMP is not supported and since it is Flash-based you will need to find a third-party player to use in your native app.
RTSP playback is supported in Android but not in iOS.
WebRTC is kind of in the same place that RTMP. It is designed for the web therefore you will also need a third-party library. This technology is gaining popularity rapidly so it will not be hard to find projects to bring support to the other platforms.

For React Native apps, you can find ports for the most common libraries in iOS and Android. Have in mind that they usually don't offer the same flexibility or expose all the features from the original ones.

2. Web browsers

Apple HLS is supported by Safari(as you should expect) in its iOS and MacOS versions.
RTMP lacks support in this area as well. With Flash out of the picture, it is not a common choice for today's browsers. Of course, you are not alone in this world, there are a few decent JavaScript implementations that you can use to play RTMP in your web.
MPEG-DASH and RTSP are not supported out of the box in any browser. You still can find open source or propietary libraries though.
Being WebRTC the most modern one, it is supported by pretty much every browser out there.

HLS and WebRTC are the options to have in mind when it comes to the playback with broad compatibility. It basically boils down to your latency needs.

Scalability

Making your platform/app able to support more concurrent users than the estimate is key. This is one of the success metrics for your live streaming app and means that your end-users will not suffer from huge delays, video stuttering, and connection drops when the numbers get high.

Here is when the delivery formats play an important role. If we will be streaming to our end users via HLS(or any of the HTTP based protocols) we are one step closer to the goal. The fact that the media chunks are sent over HTTP makes these protocols way easier to scale. The solution recommended is to put a well-known Content Delivery Network (CDN) to do all the work for us.

The high availability servers of the CDN will allow the delivery of our streaming to scale indefinitely.

By doing this we are surpassing a couple of challenges at the same time. A CDN will reduce the number of connections to our live streaming servers, allowing us to make better use of those and get the costs down. Since CDNs have servers all around the globe, it will also reduce the latency for already cached chunks when requested from regions too far from the origin servers.

Most common cloud providers and their CDNs

Bonus: Wowza CDN matches perfectly with the Wowza Streaming Engine software.

Delivering the content over HTTP is probably the best option for making your platform easily scalable.

So, what happens to the end users if you choose to stream via RTMP, RTSP, or WebRTC?
Unfortunately, traditional CDNs aren't prepared for these protocols. We need to design our own server infrastructure to handle the load and scale properly, but don't worry; this is not a new problem.

A broadly used concept is the origin-edge configuration for the core of the architecture. This defines a clear separation of responsibilities between the live streaming servers. A origin server would be the one in charge of ingesting the stream, and in some cases, also transcoding it to the delivery formats. On the other hand, edge servers will fetch the stream from the origin (or a designated transcoder) and distribute it to the end users.

This allows us to use our computing resources more efficiently. In the case of 1:many streaming applications, it allows for the distribution of connections between the edge servers, instead of overburdening the origin.

With this in mind, a common practice is to horizontally scale the core of the platform architecture. This means we will be adding more origin-edge groups as the application needs them. For the orchestration, a load balancer and an auto-scaling group can be placed around all the streaming groups.

Bear in mind this is not the only way to scale a live streaming application when using the previously mentioned protocols.

A key take away is knowing that scaling ultra low latency live streaming applications is way more expensive than using HTTP-Based protocols.

Conclusion

We hope you were able to learn more about building live-streaming apps. In the next post of this series, we will provide more technical insights. Stay tuned to see how we solve challenges on a real Live Streaming app, test scalability, and more.

Open Source

If you decide to build your own platform, want to build a quick POC, or maybe are just curious about the technologies; there are a few Open Source projects that are worth looking at.

Red5
WebRTC
AntMedia Server - Community Edition(based on Red5)

^{Icons by:

Freepik at www.flaticon.es}

What's great about our iOS base repository

German — Tue, 14 Mar 2023 11:26:27 +0000

Abstract: A prebuilt boilerplate code base can save time and effort when you create new projects. This article explains why a custom-built iOS base like ours works even better.

Summary: When you build a platform from scratch, some of the initial work might be the same for every project. You can save time by using one of many open-source code bases, or you can make your own. This article talks about the advantages of creating your own custom base.

At Rootstrap, we develop custom-made software for our clients. Like any other service, we always want to deliver the best quality product. Some of these products are native iOS applications. And that’s where our fantastic iOS design teams shines. In this article, I talk about our iOS-base repository and how it improved our team collaboration and rocket-launched development times and productivity.

The problem: repetitive work

A few years ago, we noticed that whenever we coded a new app, the work was extremely repetitive. Over and over, we created the same base project structure, copy-pasted code from previous projects, and even reimplemented entire features. But thankfully, we identified that problem quickly. In a short time, we implemented our own version of a boilerplate project.

The first solution

Our idea was simple, we wanted an XCode project that allowed us to jump right into feature development, perhaps with slight modifications or architecture changes. First, we put together everything that we needed in every new app. Those elements included a networking layer, a few handy dependencies, view customization helpers, and some useful Swift extensions. We even added example features for users to sign up and sign in to the app with local session storage.
That project was it. It wasn’t very ambitious, but it saved a lot of setup time. And now, we had something to collaborate on and improve over time.

No attachments

The Rootstrap iOS project includes basic modules like session storage, routing, and analytics. It also comes with MVVM architecture, but nothing forces developers to use that pattern or any other aspect of the main project.
As an engineer, you need to choose the right architecture for your application. Our iOS-base gives you a hassle-free way to do that.

Code quality

One implicit goal was to centralize code quality standards for all iOS developers. At the same time, we wanted the project to contribute directly to our company goals.

As a team, we reached an agreement on the requirements for good code quality and best practices. We made those standards the pillar of our code base. From there, we decided to take these actions:

Adopt these Swift style guides.
Configure SwiftLint to run locally and in the continuous integration (CI) platform of preference. SwiftLint rules respond to our agreement and the style guide.
Integrate Code Climate to ensure best coding practices.

Things changed ... for the better

If someone claimed that just by starting a new project from a boilerplate, their productivity improved by a magical percentage, I’d be skeptical. But the truth is that our boilerplate didn’t just improve productivity. It also improved many other aspects of our engineering team’s work:

Initial iterations were done faster, which grew client confidence.
Adding the iOS base to our company’s shared knowledge base helped us develop similar features in record time.
As an open source project, it generated interest in our iOS team members and increased their willingness to collaborate.
The project increased company’s visibility in the tech community.

Takeaways

You might ask “Why create another iOS boilerplate project when there are thousands of open source projects that do the same thing?” Some projects have more functionalities, and some are more specific. Despite their endless variations, you’ll never find one that solves all your specific and unique problems. Sure, you can fork the best match and adapt it to your needs. But you’ll miss a great opportunity to make the solution your own.

Key points for building your own base

These are some recommendations based on our experience:

Open source it : You can get and give help to or from other contributors. : The projects you open source showcase examples of your work and how things are done in your company.
Pet it. : Continuous improvements, updates, and maintenance are important. For example, it doesn’t look good if you last committed to your project two years ago or it’s got build errors.
Professionalize maintenance : Create a GitHub/Jira project, a Trello board, or something similar for your repository. Professional maintenance organizes your managed milestones, new feature implementation, issues, and other project elements. Collaborative team projects, task assignments, and bench management also benefit when everything is maintained in one place.
Keep it lean. : Every project has different needs. Avoid adding features that tie you to a specific implementation or service.

In other words, build something that respond to your needs, then generalize it.

Learn more

If you’re interested in the technical details of this project, check out the README at iOS-base repository.

How to Train Senior iOS Engineers

German — Tue, 14 Mar 2023 11:07:01 +0000

At this point, you’ve most likely heard of the employee training dilemma. If not, it goes like this:

Manager A: What if we train them and they leave?

Manager B: What if we don’t, and they stay?!

In other words, should we train our employees knowing they could leave the company after we invested in them? Or should we train them because we want them to (and they could) stay in the company and bring much more value from that investment?

Investing in employee training is critical to building a successful business, as it helps to ensure that employees have the skills and knowledge they need to perform their roles effectively.

At Rootstrap, we take this seriously, with one of our yearly goals being to provide meaningful experiences and career growth opportunities for our team members. Furthermore, the company's vision is to become digital masters, and investing in our team is key to achieving this goal.

In this article, we'll take a closer look at the training plan we've developed for our iOS team at Rootstrap and how it aligns with our company vision.

Rootstrap iOS Training Plan

Our goal was to have a training plan to put people on the right track to becoming senior iOS developers. Of course, completing a list of classes and reading a bunch of books doesn’t automatically make you senior, but the purpose is to set the foundations and define a clear path that a developer should follow in no particular order.

In a coordinated effort with other managers and experienced technical roles, the process began by determining the main learning modules representing the branches of a hypothetical tree. Also, we wanted to be aligned with the expected outcomes for each one of these key topics. Let's call them ‘the fruits.’
‍

As an example, we defined the Programming module as the core of the Learning Path and set the expected outcomes as follows:

Developer knows what Object Oriented Programming is all about and good practices to make the code easier to understand and maintain.
Developer has intermediate/advanced knowledge of the language and frameworks they use regularly.
Developer knows how to properly write documentation for an API and use automatic tools that use code annotations.
Developer knows what Code Smells are and remembers many of their names. While doing code reviews, they can identify them easily and make good suggestions.
Developer knows the main classifications for Refactorings and remembers many concrete refactorings. They refactor their code frequently, and while doing code reviews, they make good suggestions. Of course, each of these outcomes would have one or more actionable items that would make them achievable while going through the path. Here is the complete list of modules with a glance at their contents:

Programming:

Swift & iOS development frameworks (UIKit, SwiftUI, Combine, etc.) proficiency.
The fundamentals of API Programming and documentation.
Good practices and common techniques for debugging.

Testing:

Understand concepts around testing.
When and why to write different types of tests.
Write meaningful and valuable tests for your iOS applications.

Accessibility:

Understand basic to advanced concepts around accessibility and its importance.
How to test accessibility in your applications.
Create accessible applications.

Monitoring and Performance:

Understand concepts around monitoring and debugging mobile applications.
How to monitor applications using Xcode and third-party tools.
Techniques and how to debug applications with Xcode.

Apple App Distribution:

Understand concepts around certificates, App IDs, and provisioning profiles.
Use the different dependency managers for Swift frameworks.
Release apps for Beta Testing via TestFlight.
Create reusable Swift Frameworks.
Release apps to the AppStore.

Continuous Integration & Delivery:

Set up CI/CD workflows in GitHub Actions and Bitrise for your applications.
Submit applications to AppStore Connect via your CI/CD platforms.
Understand concepts around Fastlane tooling.

We also added supplementary modules for Git, Estimations, and Client Facing.

‍

The Nitty-gritty

Now, the developers need to be able to grow each branch, so they can finally get to the fruits, and we provided a list of tasks so they can do so. They just need to invest time in the proposed assignments for each module.

One of the requisites was having different materials for each topic. All of us learn differently; some prefer audiovisual content, while others prefer to read, for example.

With that said, we aimed to have all the most common types (articles, books, and courses) for each topic so they could pick based on their interests without missing any critical pieces.

‍
The process of picking the best-value content was hard and time-consuming. There is a lot of documentation online for any topic you would imagine. We had to assess each one of the materials we added to the Learning Path for three important aspects:

Match our knowledge expectations i.e. great content.
Be up-to-date and recent.
Conform to our average time-value expectation.

Finally, each module needed a section to put all that knowledge into practice, so we added exercises. This one was also tricky, and it took a lot of work to find practical exercises to match the needs of every single module.

We ended up going with a hybrid approach, using external sources and in-house practice tools. For example, a custom Xcode project was designed to evaluate the Monitoring and Performance module, while some open-source Katas were good enough for some aspects of the Programming module.

Centralizing The Training Plan

It was time to publish all the work and make it available for the team, and this is where Northpass came in. Northpass is a great tool used in Rootstrap University to manage the team's training. Learn more about Rootstrap's Learning Camps.

As touched on, the training plan can be completed in no particular order, and this is one of many capabilities of the Learning Paths with this tool.

We defined the modules as independent courses in Northpass that could even be accessed outside of the path itself, while in conjunction, they give shape to our Advanced iOS Engineer Learning Path.

‍

What Happens Next?

Feedback

We released the training plan, including a section to receive feedback from developers who enrolled quickly. We have already collected some positive feedback, but it is still early to make decisions based on that. The goal is to allow people to rate the quality and quantity of the content in each module they complete.

Detecting opportunities

You might wonder how we are using the training plan or how people in the team know what they need to complete. It is the responsibility of both leaders and individuals to identify which skills or learning areas to prioritize. Leaders will work closely with each developer to help them achieve their career goals.

Some areas can be used to detect goal-setting opportunities:

Code review
Devs interests
Company interests
Specific needs from sales leads or clients.

On the other hand, the team members can enroll in the Learning Path or any independent courses via our Learning Hub based on their individual goals.
‍

The Future

Managers and higher-level technical roles will push the evolution of the training plan by encouraging others to take ownership of the talent growth in the company and make it an organization-wide effort at the end of the day.

We now have a long way ahead, and this is a continuous work that will need to be adapted and improved to respond to various factors. The team and company need change, and the documentation gets outdated, new technologies emerge, and so on. More to come on this.

Growth

We've developed a comprehensive training plan for our iOS team to help members develop the skills and knowledge needed to become senior developers. By providing a clear path for growth and development, along with actionable tasks and activities, our team members will be well-equipped to achieve their goals and make meaningful contributions to our company's vision of becoming digital masters.

Overall, the training plan is a great way to retain talent, improve the team's skills and achieve better outcomes for the company. Feel free to leave any thoughts and questions in the comments section. We are happy to provide more information and take recommendations on board to help us improve.

Original post here