DEV Community: Write.as

Stupid SwiftUI Tricks: Debugging Sheet Dismissal

Angelo Stavrow — Mon, 14 Sep 2020 18:49:01 +0000

Last week, I spent some time solving an odd bug with the WriteFreely client's iOS app.

When you're looking at the list of posts, you can tap the gear button to get to the settings screen, which presents you with a form for logging into your WriteFreely instance:

As you might expect, you can tap the close button in the upper-right (ⓧ) to dismiss the sheet.

Except… well, if you tapped into one of the login form's fields, you end up in a state where tapping on the close button didn't seem to have any effect.

Okay, so that's not entirely true — if you added a print statement to the button's action, you'd find that the first tap does register, toggling presenting view's the isPresentingSettingsView flag correctly; it just doesn't have any effect.

The workaround, while I'd been testing the app, was to dismiss the sheet is by swiping down on it — a standard (if somewhat undiscoverable) system gesture.

Interestingly, when you'd tap in any form field, you'd also receive the following warning in Xcode's console:

2020-09-11 09:56:01.927435-0400 WriteFreely-MultiPlatform[37593:6860302] [Presentation] Attempt to present <_TtGC7SwiftUI22SheetHostingControllerVS_7AnyView_: 0x7fb24a7297f0> on <_TtGC7SwiftUI19UIHostingControllerGVS_15ModifiedContentVS_7AnyViewVS_12RootModifier__: 0x7fb24c905ac0> (from <_TtGC7SwiftUI19UIHostingControllerGVS_15ModifiedContentVVS_22_VariadicView_Children7ElementGVS_18StyleContextWriterVS_23ContentListStyleContext___: 0x7fb24a711ec0>) which is already presenting <_TtGC7SwiftUI22SheetHostingControllerVS_7AnyView_: 0x7fb24c80eaf0>.

There's a lot of cruft there, but it hints that SwiftUI is trying to present a view that's already being presented. This suggested to me that the hosting view is getting re-rendered when a login form field becomes the first responder, finds that the isPresentingSettingsView flag is set, and tries to present the sheet again.

Okay! This is something we can test! Here's what the settings view looked like:

import SwiftUI

struct SettingsView: View {
    @EnvironmentObject var model: WriteFreelyModel

    @Binding var isPresented: Bool

    var body: some View {
        VStack {
            HStack {
                Text("Settings")
                    .font(.largeTitle)
                    .fontWeight(.bold)
                Spacer()
                Button(action: {
                    self.isPresented = false
                }, label: {
                    Image(systemName: "xmark.circle")
                })
            }
            .padding()
            Form {
                Section(header: Text("Login Details")) {
                    AccountView()
                }
                Section(header: Text("Appearance")) {
                    PreferencesView(preferences: model.preferences)
                }
            }
        }
    }
}

(For debugging purposes, I've simplified this a tiny bit: originally that HStack was in a separate SettingsHeaderView struct.)

To test the hypothesis, I started by commenting out the entire Form. Everything then worked fine in presenting and dismissing the sheet, but of course, it's not a very useful sheet without that form. 😅

If I just included the appearance form, that works fine too. That narrows things down here — or so I thought.

There are two ways to dismiss a sheet. The first is to pass the hosting view's presentation state as a binding to the presented sheet, which is what you see in the above listing. Simplified, the SettingsView is presented from the PostListView like this:

Button(action: {
    self.isPresentingSettingsView = true
}, label: {
    Image(systemName: "gear")
})
.sheet(
    isPresented: $isPresentingSettingsView,
    content: {
        SettingsView(isPresented: self.$isPresentingSettingsView)
    }
)

You can also use @Environment(.presentationMode) in the SettingsView to dismiss itself. You declare the property wrapper at the top of the struct like so:

@Environment(\.presentationMode) var presentationMode

…and call its dismiss() method in a button action, like so:

Button(action: {
    presentationMode.wrappedValue.dismiss()
}, label: {
    Image(systemName: "xmark.circle")
})

Interestingly enough, using this method to dismiss the sheet no longer triggered the console warning when I tapped into any login form field. Could it be? Was the problem solved? 😃

Nope. 😬

If you filled out the form and logged in, then that same warning was logged three times in the console. If you logged out, the warning was logged again. But this looked like progress! It seemed likely that something in the account views was triggering this, so I explored that a little deeper.

The AccountView swaps between an AccountLoginView and an AccountLogoutView based on the state of an isLoggedIn flag in the AccountModel. My prime suspect was the AccountLoginView, which has an .alert(isPresented:) modifier attached to it. If there's an error logging in, this is triggered and an alert is presented depending on which of the three AccountError cases are present. Because the .alert(isPresented:) and .sheet(isPresented:) modifiers work similarly, maybe some wires were getting crossed there? This is, of course, a beta framework running on a beta operating system in a beta IDE!

So, I started with an easy test: commenting out the .alert(isPresented:) modifier, and see what happens on login.

You guessed it: this doesn't change the behaviour — the warnings are still logged, and the sheet can't be dismissed.

Digging further and further, setting breakpoints and stepping through code, commenting out blocks to see if they were the culprit, got me nowhere. I finally started searching DuckDuckGo for SwiftUI "Attempt to present" "which is already presenting" and eventually found this year-old forum comment on Swift.org:

Is it the current recommendation, to put modal views & the triggers outside NavigationView, or is it only to circumvent an existing bug?

🤦

Yep. Taking the .sheet(isPresented:) modifier out of the PostListView and attaching it to an EmptyView outside of the NavigationView solved the issue. Nothing in the docs on NavigationView, View Modifiers, or sheet suggests this could be a thing.

So, yeah, the title of this post is a bit misleading — it turns out that I spent a couple of hours trying to figure out what was happening, when an undocumented bug in the framework was the cause.

Again: this is a beta framework, on a beta operating system, and frankly the amount of SwiftUI documentation that's already out there is surprisingly good. But it's a little frustrating to have spent a couple of hours debugging a warning that could have been avoided with a one-line disclaimer in the documentation. Hopefully, this will be helpful to anyone that searches for a similar issue!

For those of you that want to see the code, here's the fix in the app.

WriteFreely Mac/iOS App: A Progress Update

Angelo Stavrow — Fri, 28 Aug 2020 20:21:58 +0000

It feels like it was just yesterday when I shared some initial screenshots of the WriteFreely app prototype running on iOS and Mac.

(In fact, it was almost four weeks ago.)

I've been making a lot of progress on this, and I'd love to show you where the app is today.

Pictures, Worthy of A Thousand Words

How about starting with a few screenshots? This is subject to change, but it's likely not going to change much.

Above, you'll see the current version of the app, running on iPhone and iPad.

The first iPhone screenshot shows the list of posts in my Testing collection, a private blog which I'm using for —you guessed it— testing. Tapping on the < Collections navigation link at the top-left will let you choose another collection; other buttons above and below the list let you create a new local post, refresh from the server, and access settings and preferences.

Tap on any post in the list, and you'll be taken to the app's editor, as shown in the second iPhone screenshot. Any edits you make here are saved locally, and if you like, you can publish it to your WriteFreely instance.

The iPad screenshot shows the same navigation hierarchy, and like the iPhone version, it works just as you'd expect on iPadOS — a sidebar to choose the collection, a table to choose a post in the collection, and the selected post in the editor.

Here's the app running on the Mac — the same kind of navigation, as suited to the Mac. You can more clearly see how the app's editor departs a bit from the web editor, too, with a defined area for the post's title (if you choose to add one), and another text area below for your post's content.

Oh, and of course, "dark mode" looks great. You can choose to have the app display a light scheme, a dark scheme, or to simply follow your system's setting.

Will It Post?

The basic flow of the app right now is straightforward. On launch, you're not logged in to your account, but you can create new posts that only live on your device. These posts currently show a "draft" badge, though that's going to get a less-confusing name.

As of the time of writing, the app doesn't yet store anything on disk except for your colour-scheme preference and your logged-in state, so if you quit the app —or if it crashes, which at this stage, it does every so often— you lose whatever you had. So, naturally, adding local storage is a priority.

To guard against that, you can log in to your WriteFreely account to pull in your collections and posts from the server. Those posts show up as "published", and you can edit them, at which point the "published" badge changes to "edited"; when you're done, you can push those changes to the server, which has the "edited" badge go back to "published".

Similarly, your local posts (the ones with the "draft" badge) can be published to your WriteFreely Drafts —see why it needs to be renamed?— at which point the badge changes to "published".

Tapping the reload button in the post list will fetch new content from the server. Because data loss is unacceptable, the app checks to see what the last-updated timestamps are between the local and remote copies of a post, and then applies the following rules:

If the local copy is unchanged and the remote copy is newer, replace the local copy with the remote copy;
If the local copy has unpublished changes and the remote copy is older, discard the remote copy; and finally,
If the local copy has unpublished changes and the remote copy is newer, notify the user and prompt them to make a decision:

This last bit is still under construction. Once the work is complete, you'll be able to choose which copy to keep — and of course, you'll be prompted to confirm your choice, since this will replace the local copy with the remote copy, or vice-versa.

If you log out of your account, everything is purged from the device — your collection list, your local and published posts, your logged in state, everything.

Still To Do

The easiest thing would be just link to the list of GitHub issues for the 1.0 beta — but I'm going to discuss some of the more pertinent things here, to save you a click.

Of course, saving content to your device is going to be important. There are also a couple of bugs that need fixing because they hang the app or make buttons unresponsive, so that's no good. But mostly, these to-do items fix get the user experience close to that of the WriteFreely web app.

For example — right now the app launches and drops you in the post list. It should instead drop you in the editor with a new (or recent) local post. Those local posts default to Drafts (i.e., not part of a collection), but you should be able to choose a collection for them.

Departing from other WriteFreely clients, there's an "All Posts" list which, as the name implies, shows all posts across your Drafts and your collections, all together. It doesn't, however, tell you which post belongs to which collection (neither does the editor), so that needs fixing.

And there are a few things that haven't been added as issues just yet —and maybe they won't make it into the first release— that include, off the top of my head:

Sorting the list (by created date or last-updated date, ascending or descending)
Changing the logout behaviour to keep only your local posts, and adding another setting to delete everything (the current logout behaviour)
Full-text search
Keyboard shortcuts

We're getting closer and closer to a public beta, so that's exciting! And if you want to contribute, please don't hesitate to reach out in this forum topic!

The Promise vs Reality of SwiftUI Multiplatform

Angelo Stavrow — Mon, 03 Aug 2020 20:16:37 +0000

Happy August, friends! How about an update to last week's post on the SwiftUI app for WriteFreely?

Work progressed pretty well on the shared code last week, to the point that we've got a preliminary UI that displays a list of posts, which you can filter by collection. Tapping on any post loads it into an editor, where you can make changes to the title and content.

On iPhone and iPad, there's also a new post button that will create a new draft. Why only on iPhone and iPad? Well, pull up a chair, and let's chat a little bit about the gap between the promise and the reality of multi-platform SwiftUI apps.

While I was working on the post, I tweeted that I managed to flesh out some of the key UI features for the app across iPhone, iPad, and Mac in a day, thanks to SwiftUI and live previews in Xcode 12, which show you what your views will look like next to your code, and update in realtime as you code.

I further stated:

This is building a native app with the speed of iteration that I've only ever encountered when building for the web.

(I'm looking at you, HTML and CSS. I am not looking at you, React.)

So here's what that latest iteration looks like so far, on iPhone and iPad:

And, after I installed the macOS 11 (a.k.a. "Big Sur") beta, I was able to build the Mac app to compare:

This is in no way a final UI! There's plenty of work still to be done, including replacing the unusual "picker" view for selecting the Collection with a proper sidebar, and adapting the spacing a little better on the Mac app (you can't preview anything for a Mac target, even in Xcode, until you upgrade your own machine to the macOS 11 beta).

The DX of SwiftUI, as illustrated by `ToolbarItemPlacement`

One thing that's very helpful in moving quickly with SwiftUI is how its declarative nature lets you specify the semantics of an element's placement in your view, and letting the framework figure out what that should mean on iPhone vs iPad vs Mac. A great example of this focus on developer experience (DX) is the ToolbarItemPlacement API, which lets you semantically state that a particular item that you add to a toolbar is a .primaryAction, or a .status element, and so on.

This is used in the TextEditor view to place a post status badge in the .status area and a publish button in the .primaryAction area. You can see in the screenshots I shared above how these elements are placed differently depending on whether it's being shown on an iPhone, an iPad, or a Mac — and I didn't have to write a single line of code to customize the difference.

The Letdown of SwiftUI, as illustrated by broken buttons

But life in SwiftUI is not all roses. And that's where the new-draft feature isn't quite working fully, yet. Building the iPhone and iPad versions of the app, tapping the new-draft button above the list of posts works beautifully — it slides a new draft into the list, and then opens it in the text editor for your next great essay. I was thrilled to have this working by the end of my workday on Friday.

I finished installing the Big Sur beta on my Mac this morning, excited to see how everything looked and worked in the Mac app. I expected to have some little UI refinements (that list of posts, for example, needs a healthy dose of padding), but otherwise figured that it'd be a similar experience to, at the very least, the iPad app.

And mostly, it is. The picker is replaced by a popup menu, and you can choose a collection to narrow down the list of posts. You can tap a post in the list, and it'll load it in the text editor, ready for changes. If the post's status changes, it'll instantly update the badge both in the toolbar and in the post list.

And then I tried to create a new draft. On the Mac, clicking on that new-draft button (which appears, interestingly enough, next to the post-status badge in the screenshot) does… nothing. Not a thing. No errors are thrown, no views are drawn, nothing.

The Reality of Multiplatform

I suppose I shouldn't use the word letdown, because "multiplatform" is not a panacea: the reality is that an app expects different things between an iPhone, an iPad, and a Mac. The issue I'm facing with that new-draft button isn't some failing of SwiftUI; it's that the paradigm for how a Mac app treats navigation vs buttons vs instantiating new windows is very different from that of an iPhone, and I haven't structured things the way the framework expects.

So, fine. I'll need to spend a little more time on adapting the Mac client. I would have liked it if it all Just Worked™, but I've got to say: despite a couple of little issues that I need to fix, I'm really impressed with just how much of it worked right out of the box, with no extra work on my part.

Native-app development may not yet happen at the pace of web development, but it's closer than ever.

WriteFreely SwiftUI Client

Angelo Stavrow — Mon, 27 Jul 2020 17:00:29 +0000

Hot on the heels of the developer-preview release of the WriteFreely Swift package, I'm happy to announce that work has started on a new (but related) project: a WriteFreely multiplatform SwiftUI client app.

A multiwhatsit who now?

Right. Let's clear up the jargon, first.

Apple announced SwiftUI at their World Wide Developer Conference (WWDC) last year. Initially, SwiftUI let you build user interfaces across all Apple platforms —iPhone, iPad, Mac, Watch, and Apple TV— with a single, declarative framework, ostensibly replacing the need for using AppKit (on the Mac) and UIKit (on iOS) in building your apps.

This year, Apple took SwiftUI further: you can now build entire apps in SwiftUI. And while you can still build a platform-specific app (e.g., just for the Mac, or just for Apple TV), a new template named multiplatform further coalesces developing for the Apple ecosystem.

A multiplatform app project in Xcode contains a Shared folder, in which the bulk of your app's code lives. There are also iOS and macOS folders for platform-specific customizations, but the idea is that you can use SwiftUI components to build an app that will run natively on iPhone, iPad, and Mac with almost no such customization necessary.

That's pretty cool.

So, what exactly is being built?

This is a WriteFreely client app. You'll be able to log in to your WriteFreely instance, write new drafts, publish them to a collection, and edit them, thanks to the WriteFreely Swift package. And it'll be available for iPhone, iPad, and Mac, thanks to SwiftUI.

Just like the Swift package, it'll be built in the open — the repository is on GitHub, and if you're interested in helping, check out the CONTRIBUTING doc. Developers of all experience levels are welcome to join — just let me know in this forum topic!

The goal is to go from a new SwiftUI project to a complete working app in time for the release of iOS 14 and macOS 11. The launch usually happens in September, so we want to have the app done by the end of August. That's a tight deadline, so we're limiting the scope initially to handle the key actions WriteFreely users would want: creating drafts, publishing them to their WriteFreely instance (either as a draft, or to a collection), and updating those posts.

As we build the client app, we'll be updating the Swift package as necessary. As far as I know, this will be the first WriteFreely client to consume the package, so I expect that we'll find a few surprises that trip us up as we go along. While I tried to build it as robustly as possible, that's the nature of packages that wrap an API — you only find out about their shortcomings when you start building projects with them! 😅

I'll be posting here on both the progress of the work, and the learnings that inevitably come from building a new app in a beta IDE, against a beta framework, while running beta operating systems. I've already found one UX deficiency in adding packages to multiplatform apps, and I'm sure there will be more surprises to share.

More TK!