WIP: Add ios client

[TheNoim]

Hi!

I love your apple tv client. Since I started using Floatplane I always missed an apple tv client. You really did a great job.

I don't know if I am the only person with this feeling, but I think the iOS Floatplane client is only half baked. It is slow and buggy. iOS deserve a better client.

This is why I started to work on an iOS client based on your Wasserflug. The client is far away from being finished. But before I continue with my work, I want some feedback whether you are even interested in merging something like this when it is finished.

[Jman012]

Thank you for the kinds words! It means a lot that not only do people enjoy the look and feel and experience of Wasserflug, but also that it's helping people experience Floatplane on the TV.

Wasserflug on iOS is an interesting idea. I respect Luke and the Floatplane development team and so am hesitant to introduce competition to their phone applications; especially competition against an official app with this unofficial one. The difference with Wasserflug-tvOS and Hydrvion Roku/AndroidTV apps is that we're filling in a void where the Floatplane team has not yet released apps in the TV app space. That said, it might not hurt to try. Perhaps more users are of the same mind and perhaps Luke would not be opposed to this action. He has expressed good views of the TV apps so far.

If we do continue with this, there are some things to consider:

1. Do we host both apps in this single repository (which can be renamed), or do we split out the apps into separate repositories with a third shared repository for shared views and libraries and re-usable code.
   1. If combined, I'm unfamiliar with multi-target Xcode projects and how they work. An explanation on your part might be helpful on the architectural view of this.
2. What views, view models, etc. go re-used and which go target-dependent? I think that maybe the root App and ContentView might be re-usable, but most views are probably very specific to tvOS. Most views would have to be re-created for iOS to fit the style and theme better. But, I think most view models might be re-usable easily.
3. Feature roadmap. An a personal handheld device that isn't a TV, features like comments and PiP will need to be heavily considered. They aren't as needed on a TV, but users would want them on an iOS app. Are there any other things to keep in mind on this? This would affect the view models, for instance.

And I'm sure there's more things to keep in mind. The answer to number 1 above is probably the most important and sets the stage for the rest of this project, if we do continue that. I'd want details on what the hierarchy and project structure would look like so we're all in common understanding. I could perhaps do my own research as well and do the architectural organization on my side, commit that, and have a blank canvas to work on for iOS once I'm happy that the project allows tvOS to live in one space untouched, and iOS in another, with both sharing some code.

Cc @bmlzootown for discussion on entering into the iOS/mobile space with unofficial apps.

[Jman012]

I'm getting a better understanding of the layout, now. I see that the core app setup is moved to its own component, we have an App for tvOS in its original place and for iOS/macOS in the Shared folder. The new views you've created are in the Shared folder, and the tvOS views in their original place are modified iwth the #if os(tvOS) for multi-targeted builds (perhaps we'll fine tune this so that those don't even get built when building for iOS. I think this is possible with which files get included in the Build Phases. Something to look into later).

We now have a tvOS folder with tvOS-specific views, and a Shared folder with views used outside of tvOS. The stated goal for this PR is making an iOS client. Would it be good to make the Shared folder named something closer to iOS? Or are you also envisioning a macOS client?

For the mockIsLive in the view model, perhaps we can leave mocking code out of the main code by changing what gets injected as the FPAPIService with different mock data? It's a tad annoying since the mock data is quite large, though :).

[TheNoim]

Thanks for the response!

I also respect the work of the Floatplane team. They still released an app even though they had many problems with the publishing process in the AppStore. However, I think this is the reason why we will not get a polished app for Floatplane anytime soon :/ I have the following view on this:

The Floatplane team currently has no capacity of releasing a new and better app version. At least this is what I understand after watching some WAN episodes. I still can be wrong. But I think an alternative open source Floatplane client can overcome this "weakness" of Floatplane and actually help them :) You don't earn any money off it or prevent a user to join Floatplane. Maybe this can even drive more users to Floatplane and this would be awesome! :D

Let's now get to the other questions:

1. At this point I don't know. I only develop iOS Apps in my free time. However, if I look at other projects and at some requirements for features like DeviceDiscoveryUI, one single project might be better. This also makes it easier to update both apps at the same time. Maybe splitting up makes only sense for larger teams and bigger projects. In addition, sharing models and functions doesn't involve a separate release process for a shared library. My take on this PR probably still needs some touch up, but the multi target Xcode project works.
2. Yes, you are correct. I was able to use most ViewModels without a problem. Maybe some need slight modifications, but at this point it works good. And even some views can be reused. Of course, most of them need a rework, but some of them also work on iOS with a small modification. This is the power of SwiftUI! :D
3. I will post a roadmap at a later time.

I'm getting a better understanding of the layout, now. I see that the core app setup is moved to its own component, we have an App for tvOS in its original place and for iOS/macOS in the Shared folder. The new views you've created are in the Shared folder, and the tvOS views in their original place are modified iwth the #if os(tvOS) for multi-targeted builds (perhaps we'll fine tune this so that those don't even get built when building for iOS. I think this is possible with which files get included in the Build Phases. Something to look into later).

Only files marked for the iOS target get included in the build process for iOS. Vice versa with tvs.

However, I need to admit I still don't like the structure. There should be at least three folders: tvs, iOS and shared. Then it is more clear which files are used by both targets and which by only one. The folder itself isn't important as long the correct targets get selected for the file. But it still helps to keep it organised. Especially, for viewing PRs on Github.

You only looked at the PR on Github, right? Only in XCode you can see which file belongs to which target.

Example, a file only used for iOS:

A file used for both:

We now have a tvOS folder with tvOS-specific views, and a Shared folder with views used outside of tvOS. The stated goal for this PR is making an iOS client. Would it be good to make the Shared folder named something closer to iOS? Or are you also envisioning a macOS client?

At least I want to keep the door open for a potential mac client. I haven't tried running it on macOS, but maybe it will work out of the box for free.

For the mockIsLive in the view model, perhaps we can leave mocking code out of the main code by changing what gets injected as the FPAPIService with different mock data? It's a tad annoying since the mock data is quite large, though :).

Ok, sure. This was only a quick way to test it.

[Jman012]

Agreed on all points. Single project will be easier to handle for a small app at this time.

Understood with macOS, we can keep those in Shared or make that third iOS folder. I'll leave thatu p to you.

Good to know you already handled the target membership 👍.

[TheNoim]

Roadmap:

• Video playback
• 2FA support
• Home and creator feed
• Responsive layout
• iPad support
• Save watch progress
• Video quality selector
• Accessibility
• Live stream support
• Comment section
• Make view under video scrollable while watching the video
• PiP
• Re-Organization of the code structure
• Fitting launchscreen
• 4K Support

Optional/Future:

• iCloud synced watch progress?
• tvOS Remote? Start playback on iPhone and handoff to tvOS?
• tvOS login via iPhone App?
• Download?
• iCloud synced Watch list?
• Timestamp sharing?
• Open Floatplane links in app
• Browse creators?
• macOS App?

Probably not possible at the moment:

• Notifications

Current screenshots:

[JoshuaHolme]

Is this project dead? Curious if anyone is still working on this. I use this app regularly to watch floatplane on my TV. Would be devastated if it was abandoned

[Jman012]

Wasserflug for tvOS isn't dead! Not much to work on recently though so I haven't made too many updates or additions.

I think that this iOS fork isn't being worked on anymore though. The person who started it hasn't done much since opening this request

[JoshuaHolme]

Is the TestFlight still the best version? Or is it safe to use the App Store version?

[Jman012]

As the Readme states, Test Flight is still the best option :)