How radical contributions would you accept?

[myyra]

Hi, I was pleasantly surprised to find a native and open source client for Jellyfin! It works really well, except for an audio sync issue on Apple TV when using HomePods.

I cloned the project to start looking into it, but I noticed that you are using many practices that are not ideal for a production app or long-term maintainability. I know this since I've done many of those things in the past and have since learned from them.

I was just wondering how radical contributions would you accept if I was to start improving these things?

But even before that, I'd like to ask about the indentation. Why tabs? This is the first Swift project I've seen that uses them.

[LePips]

Hi and thanks for your interest in contributing!

To first answer your question, every project I've done uses tabs so I don't understand why this seems weird, sorry.

I do personally observe some tech debt we have, but nothing "not production ready" like you observe. What examples do you have?

Also, if you want to contribute when it comes to video playback, please look into VLCKit and the problems that it has because then we carry it over. The HomePod issue is due to VLCKit.

Edit: realizing I didn't really answer your overall question:

We welcome almost any "radical" change. The app has practically been rewritten since I've joined. We would just have to discuss what the change is, it's pros and cons, whether we want it, etc.

[myyra]

First of all, sorry for the late reply. The notification got buried in my endless GitHub list, which I'm only cleaning up now.

every project I've done uses tabs so I don't understand why this seems weird, sorry.

No need to be sorry. In my 8-year Swift career, this is the first project I've had on my computer that uses tabs :D Of course, I have many Go projects that use tabs, but this is the only Swift one.

I do personally observe some tech debt we have, but nothing "not production ready" like you observe. What examples do you have?

Crucial note on the wording: not saying the app itself isn't production ready. It's more about development practices. Some things I'd change myself if I were to manage this project:

Remove all compiled dependencies from Git. It makes the repo huge and slow in the long run. And nothing is more annoying than slow Git.

There are a lot of dependencies for this small of an app. Many of which could be replaced with very little custom code. While dependencies are fine when iterating quickly at the beginning, they tend to become liabilities sooner or later.

I'm especially wary of building the whole navigation of the app on top of a dependency. But I know I'm quite a bit more strict on dependency use than any iOS dev I've met.

And maybe this is more subjective, but I find the Objc style indentation quite tedious to read these days, and find this way Swiftier:

- func requestLatestMedia() {
- 	LogManager.log.debug("Requesting latest media for user id \(SessionManager.main.currentLogin.user.id)")
- 	UserLibraryAPI.getLatestMedia(userId: SessionManager.main.currentLogin.user.id,
- 	                              parentId: library.id ?? "",
- 	                              fields: [
- 	                              	.primaryImageAspectRatio,
- /// ...

+ func requestLatestMedia() {
+    LogManager.log.debug("Requesting latest media for user id \(SessionManager.main.currentLogin.user.id)")
+    UserLibraryAPI.getLatestMedia(
+        userId: SessionManager.main.currentLogin.user.id,
+        parentId: library.id ?? "",
+        fields: [
+            .primaryImageAspectRatio,
+ // ...

That is especially one thing that is just the authors' preference sometimes. And even if there could be an objective discussion on the benefits (better GitHub PR diffs because the lines are shorter and easier to track most of the time), style is style in the end.

So nothing huge, at least without a deep understanding of the project. Just small things that make a project more ergonomic to work on in the long run.

We would just have to discuss what the change is, it's pros and cons, whether we want it, etc.

Of course. If I make a PR for someone else's project, I ensure all my reasoning is appropriately documented there, and then the discussion can start—just basic contribution manners, in my opinion.

Now to the original issue: I noticed that VLCKit has trouble playing HDR content correctly, so I'm not going to try to fix it. I guess I need to start figuring out the native player and why it only plays audio for me currently. It seems this is a known issue with HEVC?

[nyvelius]

If indentation is brought up as an issue, that's an indication the application is pretty great. :)

So far 'it just works'. Nice work!

[LePips]

tabs

I see now what you're pointing out specifically. This is just a result of the --indent tab rule in our formatting, and honestly now that I'm playing around with it I might be more inclined to remove that rule. Doesn't change anything really.

compiled dependencies

These specifically are just a result of the ChromeCast SDK just recently making their frameworks compatible for M1 development and moving away from CocoaPods. I thought they were fine as they're rather small and don't impede git at all.

Since you brought it up, I was able to think about experimenting with adding a "spoof" Carthage Binary Project Specification file to the repo that just points to the libraries and then use that in the Cartfile. I'll play with that. However we just have to hope that Google will make these available through Carthage.

dependencies

We heavily rely on our dependencies for their overall functionality, so copying them over would be more problematic as they wouldn't be small.

• swift-algorithms is only used for one algorithm for computing the time between chapters, however the implementation of the algorithm is very complex in the source. This might not be needed in the far future with some Chapter changes briefly discussed among the server team.
• CombineExt will most likely be removed when I refactor searching, but has the same justification for existing now as swift-algorithms.
• There was a small file we used and was replaced by a Carthage package in Use UDPBroadcastConnection library #474, however the comment there readily justifies its use and I want to make a PR on the source to make it available for SPM. This would be a "small" thing to include ourselves however it's a very distinct package with a clear purpose. Also, having it as a package removes an annoying warning that can't be removed.
• ParallaxView is being removed.
• I want to take a look at replacing ActivityIndicator with something that works better for us while handling API calls.
• Puppy I plan on either forking or replacing just due to some differing development preferences I've had with it.
• Many other of the dependencies are external dependencies of the packages we've specified.

As with the discussion with 1st party solutions vs 3rd party libraries it's about what functionality they provide to us. We heavily use the dependencies that are the most useful to use, like our navigation package Stinsen. I have gotten very familiar with the source, have contributed a bit, and plan on contributing more with the new iOS 16 APIs. We also use packages to handle our CoreData, UserDefaults, and localizations. These packages provide a ton of functionality and ease of use over default solutions which only get us so far.

It's always our responsibility to know what our main packages are and the usage of 3rd party libraries is encouraged by the community. They take away a lot of management and concern from us which we need and in-house alternatives are only preferable if they provide the same functionality relatively easily or provide more specific solutions (ActivityIndicator and ImageView.swift). I lean more towards the side of pro-3rd part libraries but I'm also picky sometimes as well and try to get familiar with them as much as I can for what I am using them for.

argument and parameter styling

Since you bring it up and I've tried it, sure! These just require two changes in our SwiftFormat file.

VLCKit and hevc

I haven't touched anything for playback in a while so I'm not too familiar with the audio-only issue for hevc. For anything related to VLCKit, you would have to look at the VLCKit repo or VLC itself. Here's the issue about HDR specifically. I have been looking at moving over to mpv for a while however other development needs to happen first.

Overall and again, thanks for your interest in the project!

[LePips]

I just went ahead with the SwiftFormat changes and the Carthage updates, as the Carthage thing actually isn't a hack and is an intended use of it.

[LePips]

Since I saw it again, I did copy over TVOSSlider.swift which originated from somewhere on GitHub and I made necessary modifications. I will be making this probably entirely custom in the long run for us.