I primarily use the PWA when visiting this site using an iPhone 16 Pro Max.

There are several theme usability issues that would be obvious to anyone using the PWA for a couple of days.

Please have your devs spend time on testing out the UX specifically on the iOS PWA before releasing the v5 GA.

Specifically, I am unable to post using the PWA so I’m posting this in Safari. I think I might have taken time to report this one bug already, but almost every time I use the PWA I see issues with the theme that I simply don’t have the time or energy to report.

A good week of thorough testing of the PWA would be very welcome by me as I intend to enable the PWA for my upcoming v5 site and it is important to me that the UX be as good or better than using a browser.

The issues are undoubtedly from Webkit in the PWA being several releases behind Safari and your devs using Safari or Chrome and not the PWA for testing.

I‘m not having any issues to reply with PWA, the editor loads fine for me.

There must be something else going on. What iOS version are you using?

6 minutes ago, Daniel F said:

I‘m not having any issues to reply with PWA, the editor loads fine for me.

There must be something else going on. What iOS version are you using?

18.2.1 (the latest version I think).

Maybe there is a JavaScript exception preventing the keyboard from appearing to input text?

I do have the fastest iPhone and I think this prevents me from seeing edits to posts unless I force a page reload to see the changes.

So, maybe the issue is only on very fast iPhones where there is some sort of asynchronous JS that gets handled out of the usual order sometimes.

I did notice that around 10% of the time I can see edit changes without reloading making me think that some of my PWA UI issues are JavaScript related and maybe hard for you to reproduce?

This is what Claude says to see JavaScript exceptions on my iPhone. I’m not going to take the time to do this, but maybe this would explain what I’m seeing, if this works for debugging a PWA.

Claude 3 response via duck.ai

To see JavaScript exceptions in Safari on your iPhone, you can follow these steps:

1. Enable the Develop Menu in Safari: Go to Settings > Safari > Advanced and turn on the "Develop" menu.

2. Connect your iPhone to your Mac: Use a Lightning cable to connect your iPhone to your Mac.

3. Enable Web Inspector on your iPhone: On your iPhone, go to Settings > Safari > Advanced and turn on "Web Inspector".

4. Open the Web Inspector on your Mac: On your Mac, open Safari and go to the "Develop" menu (which should now be visible). Hover over the name of your connected iPhone, and then select "Show Web Inspector".

5. View JavaScript Exceptions: In the Web Inspector window, you should see a "Console" tab. This is where you can view any JavaScript exceptions that occur while you're using Safari on your iPhone.

When a JavaScript exception occurs, it will be displayed in the Console, along with information about the error, such as the line of code where the exception occurred and the stack trace.

Keep in mind that the Web Inspector feature is primarily intended for web developers, so it may not be the most user-friendly way to view JavaScript exceptions for non-technical users. However, it is the best way to access this information on an iPhone.

I know I said I wasn’t going to do this, but I did and the Web Inspector console shows no exceptions when replying to this topic and the keyboard doesn’t pop up to enter text into the editor.

Here is a screenshot of the console:

I’m trying editing a reply to see if that throws an exception.

Here is my edit.

This edit showed up this time.

It is working every time when the Web Inspector on my Mac is connected.

Maybe this bug really is a timing issue with very fast iPhones.

Disconnecting cable to MacBook Pro for this edit.

Yes. With the cable disconnected I don’t see the edit until I reload the page.

This last one worked while the previous one didn’t.

Edited Wednesday at 08:03 PM1 day by KT Walrus

Maybe this timing bug is related to the size of the reply. Trying one more time with a short reply.

Here is my edit.

That failed to show.

Here is a longer edit:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

That failed to show either. Maybe this will show up?

Nope. Didn’t show up either so theory about size of post is wrong. Maybe it really is a timing bug that can be avoided when cable is connected to MacBook Pro web inspector console.

Connected to Mac for this edit.

That showed up kind of confirming it is a timing issue.

Edited Wednesday at 08:13 PM1 day by KT Walrus

Does this site use web sockets?

I’m seeing some connection errors when switching between the PWA editor and the editor in Safari on same iPhone.

Here is a screenshot:

Doesn’t matter which way I switch. Either to or from Safari from or to the PWA. I suppose web sockets aren’t shared between two processes. Still, I think the JavaScript should try to connect to a new socket if the current socket goes wonky. Maybe I just needed to refresh the page though to get a new connection.

This might be a DDOS vector for overwhelming the Invision Cloud service.

I don’t think this happens with my Laravel app but I am no longer experimenting with Web Sockets in Laravel any longer.

Edited Wednesday at 08:37 PM1 day by KT Walrus

Testing reply from PWA.

Edit: below was a separate post that was merged

iPhone 16. No problems?

Edited Wednesday at 11:14 PM1 day by Day_

I’m wondering if anyone here also has an iPhone 16 Pro Max and see if my issues can be replicated by others.

The fact that the edit problem occasionally works and always works when my iPhone is connected to my Mac really seems to indicate that there might be an async issue with the editor’s JavaScript. I also have fast wi-fi and if the editor is using web sockets somehow on this page, that might explain some of the issues I’m seeing.

I’m wondering if switching to 5G cellular would make any difference. I’ll try that now.

No difference on 5G with the edit changes. Still not showing up without a reload.

Maybe this is a React thing with the shadow DOM?

Edited yesterday at 02:30 AM1 day by KT Walrus

Testing posting using a 15 Pro Max.

Adding an edit.

Ok, I can post fine using an iPhone 15 Pro Max.

“[After editing, ]Still not showing up without a reload.”

Yes, this has re-appeared and I’ll debug.

51 minutes ago, Matt said:

Testing posting using a 15 Pro Max.

Adding an edit.

Ok, I can post fine using an iPhone 15 Pro Max.

“[After editing, ]Still not showing up without a reload.”

Yes, this has re-appeared and I’ll debug.

Were you unable to reproduce my other big issue with not being able to bring up the keyboard for text input in the PWA?

I do have the Emoji keyboard enabled but I disabled it and my issue still remains.

BTW, no text input fields bring up the keyboard in the PWA, not just for the editor. For example, I can’t even type in a new topic title in the PWA.

Found this webkit issue on my keyboard issue in PWAs on iOS.

https://bugs.webkit.org/show_bug.cgi?id=279904

Keyboard issue fixed 👍

Cleared website data for this site in Safari settings. This did nothing.

I then deleted the PWA, rebooted, and reinstalled the PWA.

This did fix the keyboard issue.

I believe the real issue is a bug with PWAs that were installed before upgrading to iOS 18.

I installed the Invision Community PWA years ago.

This also explains why Invision devs couldn’t reproduce the issue on their iPhones. Probably nobody at Invision uses the PWA and had to install it again after upgrading to iOS 18 and IC v5.

This is speculation on my part. I still would like to see Invision devs use the PWA full time for a month or two. This would shake out any remaining UI and UX issues (like not having an obvious way to reload a page).

Edited yesterday at 01:52 PM1 day by KT Walrus

Yes, we want to bring a lot of improvements to the PWA and mobile use in general over the next handful of releases.

45 minutes ago, Matt said:

Yes, we want to bring a lot of improvements to the PWA and mobile use in general over the next handful of releases.

The biggest issue I see now, assuming you fix the edit changes not showing up without a reload of the page, is with missing pull to refresh and navigation controls like back, forward, reload, and scroll to top in the bottom menu nav in the iOS PWA

Fortunately, both these are very easy to implement with a little JS and have almost zero risk of breaking anything else.

I also exclusively use Fluid View for the Forum Topics page. In this view, I occasionally filter the forums by selecting the Feedback forum. It used to be the case that when I wanted to switch back to showing all forum topics, I could uncheck the Feedback forum and all forum topics would show. This is no longer the case. The Feedback forum remains checked after trying to get back to all forums. I now have to manually check all forums to see everything again.

This could be better like having all or none links like is an option, I think, on checkbox sets in the form helpers.

One other related issue is when you click on a forum link in the topics fluid view, it auto selects that forum in the forums filter, causing me to have a hard time getting back to having all forum topics again. I often don’t realize I am only seeing the Feedback topics for days since I didn’t explicitly check the Feedback forum in the filters but it was implicitly set when I clicked on a forum link.

This is also a very easy problem to fix.

I hope you find the time before the GA to address these issues since I believe it wouldn’t take much time and would improve things on mobile. V5 is much better on mobile than before, but just needs a little attention from your devs to make the PWA usable for non-technical users.

20 minutes ago, KT Walrus said:

and navigation controls like back, forward, reload, and scroll to top in the bottom menu nav in the iOS PWA

There’s a setting for this in the ACP

6 minutes ago, Daniel F said:

There’s a setting for this in the ACP

I already knew this.

That doesn’t solve the navigation issues if you want your PWA to look like a native app on iOS. You don’t get back, forward, reload, and pull to refresh.

Apple doesn’t want PWAs to look like web apps but more like native apps. So, they don’t add any chrome to the UI of the app. It is up to the PWA to provide the users with the navigation controls in order for the end user to use the PWA like they would any native app.

It is easy for PWA developers to add such navigation into their UI in a way that makes the most sense for their PWA users, just like if you were to develop a native app for those users instead.

It is a true disappointment to me that IPS didn’t fix the PWA in v4 years ago. You seemed to release the feature with a promise that you would fix these UX issues over the next several releases.

So, I have been waiting almost 2 years now for you to release v5 with a good UX in the PWA only to read that IPS plans to make major improvements to the PWA over the next handful of releases.

As I recall, this is the same response when I complained about the PWA when it was first released in v4.

This is beyond frustrating to me so I guess I should shut up now and move on. I won’t bring this up ever again.

16 hours ago, KT Walrus said:

I already knew this.

That doesn’t solve the navigation issues if you want your PWA to look like a native app on iOS. You don’t get back, forward, reload, and pull to refresh.

Apple doesn’t want PWAs to look like web apps but more like native apps. So, they don’t add any chrome to the UI of the app. It is up to the PWA to provide the users with the navigation controls in order for the end user to use the PWA like they would any native app.

It is easy for PWA developers to add such navigation into their UI in a way that makes the most sense for their PWA users, just like if you were to develop a native app for those users instead.

It is a true disappointment to me that IPS didn’t fix the PWA in v4 years ago. You seemed to release the feature with a promise that you would fix these UX issues over the next several releases.

So, I have been waiting almost 2 years now for you to release v5 with a good UX in the PWA only to read that IPS plans to make major improvements to the PWA over the next handful of releases.

As I recall, this is the same response when I complained about the PWA when it was first released in v4.

This is beyond frustrating to me so I guess I should shut up now and move on. I won’t bring this up ever again.

Sorry to hear you are frustrated there. All I can do is re-iterate what Matt has already said there. Version 5 is built with mobile in mind, so provides us with a better framework in which to build on things like how it shows in a PWA environment, but we are not going to get everything done in the first release, or we would simply never end up releasing it.

It would probably take a miracle from the heavens above to restore this feature, but I’ll leave my feedback nonetheless. I have this third-party feature called “reaction in private messages," where members can express their reactions in private messages. Due to removing the hooks in v5, I was told this feature is impossible to recreate in v5; the only option is for IPS to include it in the core. This one feature is the one I missed the most in v5. I read it only takes one line of code to apply this feature. By any chance, can we react to private messages in v5?

6 minutes ago, beats23 said:

It would probably take a miracle from the heavens above to restore this feature, but I’ll leave my feedback nonetheless. I have this third-party feature called “reaction in private messages," where members can express their reactions in private messages. Due to removing the hooks in v5, I was told this feature is impossible to recreate in v5; the only option is for IPS to include it in the core. This one feature is the one I missed the most in v5. I read it only takes one line of code to apply this feature. By any chance, can we react to private messages in v5?

You need to post this in your own feedback item, rather than in an unrelated topic

Just now, Marc said:

You need to post this in your own feedback item, rather than in an unrelated topic

My bad; I thought this was the official feed topic.

1 hour ago, beats23 said:

My bad; I thought this was the official feed topic.

Not a problem 🙂

3 hours ago, Marc said:

Sorry to hear you are frustrated there. All I can do is re-iterate what Matt has already said there. Version 5 is built with mobile in mind, so provides us with a better framework in which to build on things like how it shows in a PWA environment, but we are not going to get everything done in the first release, or we would simply never end up releasing it.

I understand that making the PWA truly work like a native app, like including page caching and offline use is a lot of work and should be deferred to subsequent v5 releases.

But, the work to make the default theme’s navigation controls for the iOS PWA wouldn’t take much time and would make the PWA UX great for non-technical users in the first release of v5.

All that is really missing is pull to refresh and back/forward/reload/pull controls placed somewhere in the UI. The perfect place in my opinion is the Navigation Menu on mobile (phones and tablets).

I don’t really understand why this couldn’t make it into the GA. It seems trivial to implement using very little JS. Maybe I don’t understand why it is taking more 2 years to make these changes.

I realize this is only a problem with iOS and not Android or Mac PWAs.