Are you tired of spending hours watching YouTube videos? Do you wish there was a way to quickly extract the most important information from those videos without wasting your time?

Artificial intelligence might just be the solution you’re looking for. AI can help you filter through hours of content to find the most relevant information in just a matter of minutes by generating concise summaries.

AI summaries can come in handy when you want to,

• Quickly review the highlights of a long lecture or presentation.
• Get the gist of a news segment or documentary.
• Take notes of a recipe or any DIY video.

One iOS app that’s leading in this space is Skryb AI. This app generates easy-to-read, bullet-point summaries of videos with a simple and intuitive user interface. You can quickly browse through summaries of multiple videos to find the exact information you’re looking for.

Not only it saves you time, but also helps you retain more information by providing succinct summaries. You can quickly review key points and better understand the content of the video. Also, all summaries are saved locally on your device and you can use the search revisit info quickly even when you forget.

In conclusion, if you’re tired of wasting time on YouTube and want a more efficient way to consume video content, AI technology and apps like Skryb AI are the way to go. Get it for free from here and see how much time you can save. You can upgrade only if you find it useful.

Productivity boost: Stop wasting time on YouTube, use AI instead to get info from videos quickly was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last month, I had idea for a new app and as usual, just wanted to build it. But this time, I want to build in public.

Before starting, I wanted to spend some time finding out if there are any apps out there, that would help me solve the problem.

A short article about my findings!

First let me explain the problem.

As muslims, we get a Imaan boost every Ramadan. And for the past few Ramadans, I try to listen to some Tafsir of the Quran (mostly by @noumanbayyinah, @YasirQadhi or @muftimenk) and try to memorize those surahs/ayats.

But after Ramadan is over, we hardly keep revising what we learned and end up forgetting it by next year. So this time, I was thinking of how to NOT forget whatever I learn.

As an app developer, for every problem the first solution that comes to mind is an App.

¯\_ (ツ)_/¯

What I would like the App to do is to track what all parts of the Quran I have memorized and remind me when I want to revise which part, so I that I don’t forget it.

And recently, one of friends was talking how a Spaced Repetition app has helped him learn a new language. 👏

I’ve known spaced repetition to be a good technique for learning and retaining what you learned. It makes sense that we do the same with memorizing Quran. I spent some time reading about it and I agreed more with that thought.

After all, this is what the Ustaadhs in most Hifdh madarsas have been doing for centuries. Make students revise particular portions at specific time intervals. They just didn’t come up with this nice name for the technique. ¯\_(ツ)_/¯

I searched in the App Store to find out apps that would help me track Quran learning and also remind me to revise it at spaced intervals. I couldn’t find any. 😞

Most of the apps which are out there for memorizing Quran just play recitation of selected verses repeatedly.

While that certainly helps in memorization, not so much in retention. Irrespective of whatever keyword I used for searching, I couldn’t find more than a handful of apps. Some apps were not even in English.

I think the state would be different in Play Store. Maybe.

I came to conclusion that iOS certainly needs more apps for Muslims. Well, that way, it helps me work on something and feel good about it as well. Because this could also be spending in Allah’s path 🤩.

But anyways, I started looking the other way around. Tried a few Spaced Repetition apps and saw if I could use them to revise Quran, instead of just some flash cards with new words.

Theoretically, that should work. Practically, it was cumbersome.

If any of you know apps that would help me solve the problem I described here, kindly let me know. Even though I’m halfway through my app, I would gladly try any existing solutions first.

Inspiration from @ThePillarsApp helped me not delay building or think too much. A couple of weeks ago, I started working on it and AlhamthuLillah, it has turned out good. And I’m trying to use it regularly.

I’ll post another article about the progress, maybe after I have some pretty screen shots. 😉

Update June 17, 2021: I made a basic MVP of this idea and shared the iOS app beta via TestFlight with a few users. If you are interested in trying out the beta, kindly DM me on Twitter or email me.

SwiftUI is really easy and fast for prototyping UI. This opinion has been expressed by many developers in different wordings.

But how does SwiftUI fare against the complex requirements of a real-world project? At present, it has been in production for only just over a year, and we can’t find many SwiftUI apps in the App Store.

But if there is any good time to build and ship SwiftUI apps, it is right now.

Disclaimer: Your app’s minimum target needs to be iOS 13.

Even though most of the SwiftUI features which make it production-ready have shipped only with iOS 14, you can build a decent app for iOS 13 which becomes exceptional when the user updates.

Take the common requirement of a collection view in many apps. You can use the new lazy grids for iOS 14 and drop down to a combination of VStack and HStack as Paul explains in this article for iOS 13. Also, if your requirement can just be fulfilled using a list, then go for it in iOS 13.

But if your requirements are complex or you want to tweak the default behavior a little bit, you might find it difficult. Today we’ll tackle one such scenario where I want some tweaks to the default behavior. Over the coming weeks, we’ll see many more.

SidebarListStyle was introduced this year, and makes it so easy to get the default sidebar behavior in your app.

Just with those few lines, you get the default behavior of the sidebar in a nice master detail layout.

You get a lot of things out of the box: a sidebar with spaced out list items, no separators, a nice indication for the selection, and a button to toggle the visibility of the sidebar. If you use the new Label for the list item, the images will be in the accentColor. So cool, with just a few lines of code! Now my requirement is to have the sidebar and the detail view, but I don't want them to be inside a NavigationView. Sounds simple, right? Let’s try.

And the output is…

Not what I expected to see from the above code. But SwiftUI views react to the environment; you can say that SwiftUI views are dependent on the environment. We got the spaced-out list items without a separator but no selection and hence no highlighting when tapped, and we need to frame the views in the required size.

I have no clue why removing the NavigationLink stops the List selection from working. You can get it to work by adding an onTapGesture to the Text. The selection parameter in the list in no longer required. You can fix the sidebar width by using the frame modifier.

Let’s try our luck this time.

Again, this is not what I expected, but SwiftUI did its job perfectly. We can fix this easily by adding a Spacer() before and after detailView.

The functionality is working properly, so you can tap any item to select it. But there is no visual indication of which item is currently selected. To highlight the selection, add a background with accentColor.

Here’s the final output.

And here’s the code to get that output.

We’ve used an HStack and a contentShape modifier so that tapping anywhere on the list item enables selection.

This is not the perfect solution, but this works. It took me some mental preparation to share working solutions publicly rather than waiting for the perfect solution all the time.

Happy coding!

Using Sidebar in SwiftUI Without a NavigationView was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

A major paradigm shift is in progress in the Apple development world. For years, we were used to the imperative programming style of UIKit and AppKit. Even though there were many attempts by third parties with different styles, this imperative style of UI frameworks remained the same and most developers liked it.

When Apple introduced SwiftUI in 2019, the future looked distinctly different. It’s all declarative now. Not everyone was ready to jump in from the onset, but for those who dove into SwiftUI, it is a fun if occasionally frustrating journey. With the improvements SwiftUI is getting in 2020, more developers are set to begin their journey with a declarative UI framework.

Let’s try to explore the workings of one of the most important parts of SwiftUI: modifiers.

A View can have any number of modifiers. They can be added to the view just like you would chain multiple function calls. Each modifier returns a View that the succeeding modifier will act on. Hence, when working with modifiers, the order in which you add them is really important. Let’s look at that with an example:

As you can see from the code and preview above, cornerRadius is applied to the inner rectangle and the whole view is rotated, as the rotationEffect modifier is the last. Now let’s change the order of the modifiers:

We’ve now interchanged the positions of rotationEffect and cornerRadius. You can observe the difference in the resulting view. The inner rectangle is now rotated and the outer rectangle is rounded.

In these two examples, we’ve applied background and padding modifiers more than once. Each time, they modified the view. Now let’s explore another set of modifiers.

In some cases, when you apply the same modifier twice, SwiftUI only takes the first one. This is clearly demonstrated by the foregroundColor modifier in the example above. This behavior is exactly opposite to how normal functions (and most of the SwiftUI modifiers) behave.

My understanding of this behavior is that when a modifier cannot have more than one effect on a view (e.g. any view can have only one foreground color), the one closest to the view is applied.

I was not able to find any documentation on why this is the case and which modifiers behave like this, but I’ve come to this understanding by working with SwiftUI for more than a year now.

How great would it be if Xcode provided us with a warning when adding such redundant modifiers more than once? Well, for that to happen, Xcode will need a SwiftUI compiler in addition to the existing Swift and Objective-C compilers.

But we can surely achieve these when we build apps that work with SwiftUI modifiers. When I first thought of solving the problems I had when working with SF Symbols, I envisioned a tool that does a better than job than the combined workflow of SF Symbols Mac app and Xcode.

Swimbols lets you add modifiers instantly, edit or reorder modifiers to suit your needs and switch symbols with just a click after applying modifiers. All with real-time preview and you can copy the code when you are done.

When it doesn’t make sense for the modifier to be added more than once, Swimbols doesn’t show them in the list. And you can add as many of the other type of modifiers we discussed earlier in the post.

You can play around with Swimbols and visually reorder the modifiers to see how they affect the view instantly.

As SwiftUI improves, it is good to have a strong understanding of the basic building blocks. I hope it is now clear how the order of modifiers affects the view and why it doesn’t make sense for some modifiers to be used more than once.

Happy coding!

Understanding SwiftUI Modifiers was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever since Apple introduced, SF Symbols life has been so easy for developers. Particularly, for those who do not a have a design team to back them up.

The pros of using SF Symbols has been documented well over the last year. There is no need to manage assets and the app size remains same irrespective of the number of symbols used. Seems like an all rosy path.

But we have one good old problem. It can even be attributed to muscle memory. To copy the symbol’s name to Xcode, we end up pressing Cmd + C, most of the time. And Xcode stops compiling when our code looks like this.

After successfully copying the symbol’s name, we modify the symbol to make is more suited for our app. Every time we add modifiers, we hope Xcode helps us with auto completion or we remember the modifiers exactly and type them correctly, so that the live preview remains live.

Then there will be times, when we might want to play around with multiple symbols, after applying your desired modifiers. So, we go the SF Symbols app, search or browse for the symbol, copy the symbol’s name, paste it into Xcode and again, hope that we did nothing to break the live preview.

Don’t you think this entire workflow needs some improvement? Here comes “Swimbols”.

Swimbols helps you overcome the pain points explained above and improve your workflow, there by giving you a productivity boost.

Here’s how your workflow will look like with Swimbols.

Browse through the categories or search for a symbol, select one and start applying modifiers. The preview is live. Just swipe left to delete any modifier. Drag and drop to re-order modifiers. Whenever you want to change the symbol, just select it. All your modifiers are applied and you can see changes without any delay. When you are happy with the design, copy code to use in your SwiftUI/UIKit project.

Swimbols is available on the App Store for Mac, iPad and iPhone. Check it out and let us know what you think.

The roadmap for Swimbols is here and you can suggest features or post issues. Keep an eye on our Twitter handle for future updates.

Happy Coding!

Re-Imagining SF Symbols Into Xcode was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working with Apple’s all-new pickers

Up until iOS 13, the options available for inline pickers felt limited. We could show the wheel inline, but that doesn’t look great in table views, lists, and forms. The other option was to use the navigation stack. But if we didn’t want to use the navigation stack, handling pickers could be painful.

Apart from those two options supported directly by iOS, many apps tried to solve this problem by showing the wheel in the keyboard area. Some apps even decided to use an action sheet, which in my opinion is a bad design choice.

Will iOS 14 help us solve this problem? If we look at the documentation for PickerStyle, there is no update for iOS 14. Where else can we look?

I was watching the Design with iOS Menus and Pickers session for WWDC 20 and there was a mention of using menus for selection.

Here’s how a simple menu looks in Xcode:

Here’s how it translates to the iPhone:

Well, this can solve the inline picker problem, but I found no help in the documentation regarding how to use it for selection.

Here’s my attempt to use the menu as a picker:

We can pass in an array of values that can be mapped to a View and an integer referring to the currently selected index.

The core work for using Menu happens between lines 30-53. When the menu is to be shown, we loop through the array and show the view for its respective index. Near the view for the selected index, we add a checkmark.

The initializer takes in an optional string, just like the good old Picker. If you want to show a name near the selected value, it will be helpful.

This can work well in most cases where our old picker was not helpful. And to top it off, we can even do this in the navigation bar and it works the same.

Now, we can go ahead and use this new MenuPicker wherever we need an inline option to select from a list of values. The full code can be seen on GitHub.

Happy coding!

Using iOS 14’s Menu as a Picker in SwiftUI was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everyone appreciates being appreciated. We can even say most people long for it. But hardly a few people will people confess how much they like being appreciated.

I’m not talking about false praise in the face. Like when a bad and corrupt politician for almost his entire life becomes President and suddenly everyone is saying how good he is and how he is the best. Seriously people? Get a life.

The kind of appreciation you get from the people who are close to you and are part of your every day life for very simple things. Your family appreciating you for getting the groceries or doing the laundry. Your manager or colleagues appreciating you for doing what you get paid to do. Your friends in class appreciating you for explaining a simple concept to them.

These are very small things and, in most cultures, nowadays they are taken for granted. You don’t expect your manager to appreciate you for doing what you are paid to do. And your manager feels no need for it, most likely does not even think about. Same inside the family or among the friends. Over time, you even stop expecting them to appreciate you for the petty things.

So, the situation is, everyone likes it, no one does it and to top it all, no one even expects it.

Where has this gone wrong? I think we lack gratitude. We will never appreciate things that we are not grateful for. We will not understand the value of such things while we take them for granted.

We have to be grateful. Someone might ask “to who?”. That is for every single person to figure out. Someone might also ask “for what?”. I think there is no point in trying to convince such a person, who might think that luxuries of life are his/her birth right. They’ll understand when they lose some.

But guess what, the other question is not so complicated. Who you should appreciate? The answer is simple. Everyone around you. Everyone you interact with often. What should you appreciate them for? For whatever good they do.

Just let people know, that you appreciate what they do and maybe even how they do. I’m sure they’ll like it and do it better next time. But don’t make a big fuss out of it. If it is dramatic, it will not be real and won’t cause any good. Just casually let them know.

To change the world for better, you can start with appreciating people. Whatever good they are doing, they’ll try to make it better.

What is it like to stare at a wall? A ceiling? The endless blue sky? or the dark night sky?

When was the last time you did so? If you are a millennial, I may have to rephrase the question to “Have you ever done so in your life”?

In this era, no one even has to look at their loved ones in the face and talk with kindness for more than five minutes. Because you know, the next notification from the new social media app will pop up and the mobile is always with in reaching distance.

Technology has made us more distracted than ever before. Tech companies have made us full time consumers. We consume content all the time, be it written, audio, video or interactive (games and social media).

Most of us never knew before what it is like to live through an outbreak of a contagious disease which has no known medicine. The pandemic and epidemic are fancy, short terms to refer to such diseases and again, most of us have not even heard these terms before.

But our ancestors have lived through it many times. And it has happened at all levels, from a village to a nation to the globe. In most places, it has been only a few weeks or months since the lock down started, and we already feel like it has been years.

Time flies — this is what we have heard and experienced all our life. And we kept complaining all the time that there is no time to do this, to achieve that. Now it feels like, for a change time stopped in its tracks, turned around, looked at you in the eye and said “Ok, I will stand still, you go ahead”.

And guess what, we are still complaining, “when will all this end?”, “when can we go back to normal?” — the very normal life which you dreaded all your life has suddenly become like a vacation spot which you want to go as soon as possible.

So now we have to step back and ask the question “who’s the one with problem here — time or me?”

Sadly, the ability the ask questions to oneself and finding answers from within is becoming a lost trait. When an online search gives us all the answers we need in the blink of an eye, why should we even care to think, reflect and seek answers from within?

All the while we were complaining that we don’t have enough time to do stuff, now we are complaining we are not having enough stuff do.

By standing still, time has given us the opportunity to look at our lives and improve it. The opportunity to think. The opportunity to change. The opportunity to clear all the clutter we have accumulated in our minds and in our homes (just give away whatever you have not used in the last six months to those who need it).

The opportunity to be human again and not be slaves of technology, faking a busy but empty life.

After all, still water reflects you better than muddled water.

The data flow in SwiftUI apps is different from what we have been working on for years with any other earlier imperative UI frameworks from Apple such as UIKit or AppKit.

In SwiftUI, we can just declare views and it always stays in sync with the data.

The properties in your views can be wrapped with State, Binding, or Observed property wrappers. Whenever the value of the properties provided by these wrappers changes, the view is redrawn accordingly.

Ideally, views should be small and have private State properties, with one or few Binding or Observed properties. Because, we would not want to re-draw your view often.

But then, Apple provided us with EnvironmentObject. As the name goes, an environment object can let us know of something that happens anywhere in the app to a lot of unrelated views.

Apple provided us with a long list of environment values.

In the good old times, we got to know about these changes via ViewController life cycle methods, like when a user changes theme (yeah, triatCollectionDidChange), and NotificationCenter, like when a user changes the device orientation.

These environment values can be injected into any view easily.

@Environment(\.presentationMode) var presentationMode

The above property in a view can help to know the current presentation mode or to dismiss the view manually.

We can also create our own classes conforming to ObservableObject and then make them EnvironmentObjects.

It has been touted as the next level of dependency injection. We can inject whatever you want, wherever you want. Sounds familiar? First, let us see what the Apple documentation says.

“An environment object invalidates the current view whenever the observable object changes. If you declare a property as an environment object, be sure to set a corresponding model object on an ancestor view by calling its environmentObject(_:) method.”

Does anything smell bad? What does “be sure to set a corresponding model object on an ancestor view” mean? A runtime check? What if the check fails? We’ll find out in a minute.

OK, here is a simple example for using EnvironmentObject from a Hacking with Swift tutorial.

We have two views, one to change the score and another to display the score. Both views read/write the score to the same environment object.

For this to work properly, we have to inject the environment object in the root view of the hosting controller in the scene delegate as mentioned in the tutorial.

But what will happen if we don’t inject the environment object in the root view?

Fatal error: No ObservableObject of type UserSettings found. A View.environmentObject(_:) for UserSettings may be missing as an ancestor of this view.

No prizes for guessing correctly. The app crashes with the above error. Why so?

The environment object could be nothing but an implicitly unwrapped optional, we do not know its implementation details.

But the error message closely resembles the errors thrown when you force unwrap a nil object. Also, it is quite hard to think of any other implementation for achieving the same functionality.

Now back to optionals. There has been an argument since time immemorial in the Apple developer community whether it is a good practice to use these implicitly unwrapped optional properties.

Without getting into that debate, let us find a way to ensure that these environment objects are initialized when the app is launched and ready to use in any view without crashing.

Remember, we talked about the ability to use Environment values in any view of your app. Did it sound familiar to you? The good old Singleton.

Here, we are making UserSettings a Singleton class, i.e. It is initialized on app launch and ready to use everywhere.

We have already conformed it to the ObservableObject protocol and so we can use the ObserveredObject property wrapper in the views for the UserSettings property instead of EnvironmentObject.

This ensures that whenever there are changes to the score in the shared UserSettings object, all the views that are observing it will be notified and each view is updated accordingly.

This ObservableSingleton behaves exactly like the EnvironmentObject except that it won’t crash if you fail to inject. Actually, the former provides you with compile-time safety. The code that compiles properly, should run properly — no unexpected runtime errors.

So, if compile-time safety is your top priority or you are working on a large SwiftUI project with many developers (this may not happen in the near future), Singleton classes conforming to the Observable protocol might serve you better than EnvironmentObjects.

But, do you know what the best way is to use EnvironmentObject?

Do not use it or at least reduce the usage of it. Because, both the EnvironmentObject and the ObservableSingleton stay in the memory (RAM) all the time when your app is running.

Hence, design your app in such a way that it requires very few properties to be shared across multiple views and make sure that these properties are primitive types and lightweight.

If you can design your app without any such properties, it is better for you and the app.

Happy Swifting!

The Best Way to Use Environment Objects in SwiftUI was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

You have seen the iOS lock screen, every time your phone misses to recognize your face or fingerprint. Do you want to implement the same for your app?

Let’s get started!

We are going to implement the above screen today. It can be used for entering a passcode, pin, OTP and many more.

Once you learn how this is implemented you can change the circles with squares, dashes or asterisks to suit your requirement. I implemented this primarily for OTP and circles seem the best fit for me.

Let me share the full code and explain the pieces in it, one by one.

The core idea is that a text field and the circle images are added to a ZStack at the same position, with textField above the images in Z axis and the elements in the textField are set clear color.

The images equal to the number of maxDigits, which defaults to four, are inside a HStack . Based on the number of characters the user has entered, we show a circle border or a filled circle. Tapping the showPin button which looks like an eye, will show the numbers which the user has entered.

There is no delegate to get changes as the user types in the textField. Hence, we are using this workaround of a Binding<String>. Even this entire PasscodeField is a workaround. If Apple provides a proper way to conform to TextFieldStyle protocol, none of this might be required. ButtonStyle, ToggleStyle protocols are super cool and make life much easier.

Let us get back to the code now. Every time the value changes, we call a method and check if the user has entered maximum digits. If yes, we disable the textField and call the completion handler block.

If you can notice, contrary to many implementations of UITextField for SwiftUI out in the web, I implemented this using SwiftUI’s TextField. UITextField is required only for making it the first responder on appearing as mentioned in the comments of the gist, so other things should work across all SwiftUI supported platforms.

By the way, the Introspect library I’ve used for making it the first responder is useful in other cases also. You can check it out.

Happy Swifting!