DEV Community: Mohammed Imthathullah

Why Appreciation Matters?

Mohammed Imthathullah — Sat, 12 Apr 2025 17:47:52 +0000

Especially when it comes from close quarters.

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.

A Sidebar in SwiftUI without NavigationView

Mohammed Imthathullah — Mon, 02 Nov 2020 10:24:09 +0000

SwiftUI is really easy and fast for prototyping UI. This opinion has been expressed by many developers in different wordings. Recently, SwiftLee expressed the same in Twitter.

// Detect dark theme var iframe = document.getElementById('tweet-1322862129649770499-772'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1322862129649770499&theme=dark" }

I've seen such comments about SwiftUI but this time I decided to add a response, because of the recent challenges (maybe call them limitations 🤔) I've faced with implementing some not views in SwiftUI.

// Detect dark theme var iframe = document.getElementById('tweet-1322893159009906688-683'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1322893159009906688&theme=dark" }

So, 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 Stores.

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

Disclaimer: Continue only if your minimum target is 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 and over the coming weeks we'll see many more.

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

struct SidebarList: View {

    @State var selected: Int? = nil

    var body: some View {
        NavigationView {
            List(0...10, id: \.self, selection: $selected) { number in
                NavigationLink(destination: Text("\(number) is selected"), label: { Text("Select \(number)")})
            }
            .listStyle(SidebarListStyle())
            Text("Nothing is selected")
        }

    }
}

Just with that 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, 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 Sidebar and the detail view, but I don't want them to be inside a NavigationView. Sounds simple right? Lets try.

struct SplitView: View {

    @State var selected: Int? = nil

    var body: some View {
        HStack {
            List(0...10, id: \.self, selection: $selected) { number in
                Text("Select \(number)")
            }
            .listStyle(SidebarListStyle())
            detailView
        }

    }

    @ViewBuilder var detailView: some View {
        if selected == nil {
            Text("Nothing is selected")
        } else {
            Text("\(selected!) is selected")
        }
    }
}

This is not what I expected to see from the above code. But SwiftUI views react to the environment, you can say, SwiftUI views are dependent on the environment. We got the spaced out list items without separator, but no selection and hence no highlighting when tapped and we need to frame the views in 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.

List(0...10, id: \.self, selection: $selected) { number in
    Text("Select \(number)")
        .onTapGesture {
            selected = number
        }
}
.frame(width: 200)

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 not visual indication of which item is currently selected. To highlight the selection, add a background with `accentCol

Here's the final output.

And, below is the code to get that output. Here's the [gist].(https://gist.github.com/mimthath4/4f37773f1f471bdf767ae151685414d3)

We've used a HStack and 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.

If you want to see this solution in Production, checkout Swimbols on the App Store.

Follow me on Twitter, so that I'll let you when I write more. Feel free to DM if you want to ask/share something.

Understanding SwiftUI Modifiers

Mohammed Imthathullah — Thu, 29 Oct 2020 17:27:59 +0000

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 got 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:

Image(systemName: "camera.fill")
    .padding(EdgeInsets(top: 10.0, leading: 10.0, bottom: 10.0, trailing: 10.0))
    .background(Color.green)
    .cornerRadius(10.0)
    .padding(EdgeInsets(top: 10.0, leading: 10.0, bottom: 10.0, trailing: 10.0))
    .background(Color.red)
    .rotationEffect(Angle(degrees: 15.0))

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:

Image(systemName: "camera.fill")
    .padding(EdgeInsets(top: 10.0, leading: 10.0, bottom: 10.0, trailing: 10.0))
    .background(Color.green)
    .rotationEffect(Angle(degrees: 15.0))
    .padding(EdgeInsets(top: 10.0, leading: 10.0, bottom: 10.0, trailing: 10.0))
    .background(Color.red)
    .cornerRadius(10.0)

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.

Can you tell how these modifiers are different from what we have seen above?

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.

Swimbols in action - Add and edit modifiers, change symbols and preview instantly.

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!

Re-Imagining SF Symbols Into Xcode

Mohammed Imthathullah — Thu, 29 Oct 2020 17:23:24 +0000

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.

Its quite hard to rewire ourselves, only when working with SF Symbols app.

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 - A swifty way to add SF Symbols into Xcode.

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. Tap the edit button 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.

Does it sound better than the workflow you experience everyday? Check it out for yourselves and let us know what you think. Swimbols for Mac is coming alongside macOS 11.

The roadmap for Swimbols is here and you can suggest features or post issues. Follow us on Twitter for updates about Swimbols and other exciting apps.

Happy Coding!