I'm working on an application that runs on different platforms like Windows, Ubuntu and Raspberry Pi. Think of it as a webapp served by a Python Flask server. So far I have been running the app on Ubuntu. I want to port the code and make the app run on Windows and Raspberry Pi as well.
This is what's common among all platforms - the core part of the app, the flask server remains unchanged along with the UI code
This is what's different - the data and the functionalities. If Ubuntu and Windows version of the app has a dozen features, the one for Raspberry Pi will have only half of those. The data that is needed for the functionalities also changes accordingly. Another notable change is utility functions. For ex: I will have to use different Text-to-Speech programs on each of these platforms.
It works if I create separate repos for each. I want to know what the development and code management process for such a scenario will be like. Below are the thoughts I have on mind which I feel I could try out:

Separate repos for supporting each platform
Single repo with different folders for each
Single repo with common code separated out(I'm not sure if this is doable)
Different branches for each platform support

Would love to know what the standard procedure is for such a development activity and how usual each of the above 4 approaches are(especially 4). Thanks!
Usually what one does is either some sort of feature checking or abstraction, or both.  For example, you can write an interface for text to speech and then provide an implementation for each platform.  Similarly, you can do a feature check for feature foo and then define it as absent or present on each platform.
This is the approach most codebases use, and it maintains better compatibility across versions than separate repos.  Using separate branches means you'll likely end up with a lot of conflicts merging features into various branches.
It may be that some platform-specific or feature-specific code will live in separate files or folders, and that's necessary and okay.  It may be desirable to isolate that code so it doesn't load dependencies that don't exist, for example.  But you will want to share most of the code as much as possible with uniform interfaces.
By making it feature based, you focus on the features available, so if the Raspberry Pi becomes more capable, then you just turn on the feature.  Similarly, if you decide you want to support macOS, you can just find out what features that OS can support and turn those on.  Similarly, you can add an abstraction for the native text-to-speech layer on macOS, and then flip that feature as well.
Maintain source code of app that runs on different platforms