Describe the bug
The status bar and the bottom toolbar do not follow/match either the device theme or the site theme.

Note: I looked for a repo for the new Forem app since Dev-ios is deprecated but I could not find one. If you could point me in the right direction I would gladly take a look into this myself.

To Reproduce
Steps to reproduce the behavior:

1. Go to Settings
2. Choose 'Customization' from the drop-down
3. Click on 'Dark Mode'
4. Pull to refresh
5. See that the status bar and bottom toolbar are still white

Expected behavior
I expect the status bar and bottom toolbar colors to match the website theme.

Screenshots

Environment (please complete the following information):

• Device: iPhone 13 Pro
• OS: iOS 16.0.1
• Release version: 1.4.4

Additional context
Add any other context about the problem here.

Describe the bug
When I select a photo to upload, it appears normal in the selection process, but always winds out turned 90% (top is left-facing)..
To Reproduce
Steps to reproduce the behavior:

1. Go to "write a post"
2. Click on "Upload cover image"

Wait to see it upload and note that it is sideways.

After some initial (a bit obscure) research via trial & error the WebView is exposing a few functions to be used by whomever is consuming the Framework. This is a WIP but some of the available functions are:

• load(_ urlString: String)
• setup(navigationDelegate: WKNavigationDelegate, foremWebViewDelegate: ForemWebViewDelegate)
• isOAuthUrl(_ url: URL)
• fetchUserStatus(completion: @escaping (String?) -> Void)
• fetchUserData(completion: @escaping (UserData?) -> Void)
• sendBridgeMessage(type: String, message: [String: String])
• shouldUseShellShadow(completion: @escaping (Bool) -> Void)

These will most likely change but once finalized they should go in the README and/or the official Forem Docs

Describe the bug
Currently we have sort of a bridge between web codebase and iOS-native code. This bridge helps us in controlling some very specific cases. For example:

• if user plays a podcast, from the bridge we will get the information in iOS, and then iOS native code will play the podcast using notification manager instead of playing it in website-webview.
• if user plays a video, the bridge passes the information to iOS, and then iOS native code will play the video in new full-screen activity.

Now currently for podcast the information can be sent from web-code to iOS native but we cannot send information from iOS native to web-code.

To Reproduce
Steps to reproduce the behavior:

1. Go to any podcast
2. Play the podcast
3. Once the podcast plays in iOS it will be visible in notifications section of the iOS os.
4. Pause the podcast in notification.
5. Notice that the app still shows pause icon in website.

Expected behavior
As soon as we pause the podcast in notification, the change should be reflected correctly in web-code base too.

Similar Issues

• If we remove the podcast by clearing the notification, the website still shows as if the podcast is playing, the bottom podcast bar in website should get terminated.

We haven't integrated the framework in any SwiftUI based project so far. Our lack of experimentation may translate in undetected bugs or missing capabilities.

We will appreciate any feedback if you ever find any problems when using the framework from a SwiftUI app.

Is your feature request related to a problem? Please describe.

For our first version we chose YPImagePicker because of their easy to use API and the fact that it supported all our requirements (basic Image Picker + camera photo + image crop) with the added benefit of adding filters (à la Instagram) with a nice interface.

However, we do have a few problems with it:

• It adds a few upstream dependencies that impact apps that use our framework
• It supports SPM but only on a separate branch and this causes us to be unable to rely on versioned releases
  • The SPM branch is also far behind the recent work merged to the project itself, which raises many deprecation warnings on projects that import our framework

There are some efforts to fix the problem of SPM not being fully supported but we should probably look into implementing our own solution.

Describe the solution you'd like

A simple image picker that provides two choices when triggered (use photo from library or take a picture with the camera). After a photo is chosen, if a ratio is provided then proceed with a cropping stage. This image picker would replace the YPImagePicker implementation in this function.

By implementing the image picker using SwiftUI we could greatly reduce the transitive dependencies added to projects downstream from us.

Describe alternatives you've considered

We can look into other OSS Image Pickers but I would definitely favor implementing our own lightweight picker to reduce the impact of adding dependencies to projects downstream from us.

Additional context

N/A

When I type on my phone, I often get a decent amount of latency in the input. It may be due to some kind of onkeydown that we are listening for, but it seems much more prevalent in the app context, so I figured we could start the investigation here— Even if maybe the problem needs to be dealt with on the web side.

Is your feature request related to a problem? Please describe.
Based on feedback from beta testers in TestFlight they want to have better password autofill capabilities when logging in

Describe the solution you'd like
The keyboard toolbar could be used to present suggested passwords, similar to how browsers handle it.

Describe alternatives you've considered
I'm not sure if autofill is possible directly in the form, that could be an option if it is indeed possible.

Additional context

I'm not able to get password autofill when logging in from iOS. Logging in via GitHub and Twitter have the same issue: I can go search for the right password, but it doesn't auto-detect which one I want

Is your feature request related to a problem? Please describe.
It would be ideal if we can clear the WKWebView history after a user has signed in (to avoid them going back to an OAuth page).

The problem with this is that I wasn't able to find a working solution from the WKWebView API (it seems to be read only). Looking into StackOverflow I was able to find a solution that overrides the WKWebView history implementation (#10) but it does not seem to be working good enough (swipe gestures still go back in history).

Describe the solution you'd like
A workaround in order to make the WKWebView clear it's browsing history

Additional context
PoC here: #10

Describe the bug

After an image is uploaded successfully, the markdown is injected in a readonly textbox. On its side there's a copy button, which is supposed to copy its content to the clipboard and allow pasting the text elsewhere (the editor textarea).

Although the functionality works from Safari iOS, it doesn't work from the Forem iOS app.

To Reproduce
Steps to reproduce the behavior:

1. Open the Forem iOS app on DEV or any other Forem
2. Click on upload an image and upload one
3. Wait for the upload to finish
4. Tap the "Copy" button, nothing happens

Expected behavior

For the "Copy" button to switch to "Copied" and for the text to be added to the clipboard

Environment (please complete the following information):

• Device: iPhone 8
• OS: iOS
• Release version: 14.4
• Forem app: TestFlight version 1.0 (34)

Describe the bug
When editing an existing Post and changes are introduced a "Revert" button appears but it doesn't work

To Reproduce
Steps to reproduce the behavior:

1. Go to the editor
2. Save a draft post
3. Edit the newly created draft
4. Tap on the "Revert" button

Expected behavior
A confirmation prompt should appear and if the user confirms the alert modal then the recent changes should be reverted.

This works in a Desktop browser.

Screenshots
https://share.getcloudapp.com/wbu9oLEk

Environment (please complete the following information):

• Device: iPhone 11
• OS: iOS 14.3
• Release version: v0.3.0

Additional context
Found based on report from forem/forem#12401

Is your feature request related to a problem? Please describe.
On the web we handle interactions with the Podcast/Video players using Ahoy (see podcast & video implementations)

Describe the solution you'd like
Two JS files (similar to fetchUserData.js and others) that will be evaluated when the player controls are used

Describe alternatives you've considered
Passing in the parameters with these files may be tricky, maybe worth considering passing in events into the DOM with the available sendBridgeMessage(type: String, message: [String: String]) function. This will require some work on the web repo to handle these properly.

Is your feature request related to a problem? Please describe.
"Actual size" is usually quite big, and I think the "Large" size of a photo is almost always good enough...

Describe the solution you'd like
The default in this process is "Large". I presume the user could still open this dialog and switch to "Actual size" if necessary.

Describe alternatives you've considered
I imagine there are other approaches to ensuring downsizing happens locally vs uploading the whole thing... Or maybe there is a more fleshed out photo taking and library selection library we might be able to trigger via native bridge vs the wkwebview defaults we currently use.

Some libraries I came across in a quick search...

https://github.com/1amageek/Sumo
https://github.com/longitachi/ZLPhotoBrowser

(One strictly for compression, the other more of a full-on UI)

Additional context
All in all I think getting photos more of a first class citizen will help the more non-DEV versions of our product.

Currently we have the specific ratio of 1000/420 for main images. I think this should be configurable for admins, including restricting to only square, for example, or allowing any size up to some amount.

For the time being, we should at least support passing in the ratio into YPImagePicker...

It looks like we might be able to use this config:

config.showsCrop = .rectangle(ratio: (100/42))

Or something else. Some way we should be able to pass that in.

Any scenario where we are not cropping the image (like a body image within a post or comment) we do not want to pass this config.