App db creation at first run

is is it better to have these scripts embedded into code itself or should I have physically SQLite3 files located in some settings directory which from the app loads them at first run

Having these SQLite3 files located in some settings directory will make it possible for users of your applications, or for admins installing it, to modify and/or manipulate them. So the correct answer to your question is: it depends on if you want to allow this, or if you want to prevent this. There is software where allowing other people this kind of customization is perfectly fine, and there is software where allowing other people this would be hazardous. So pick your choice what in category your app falls.

Moreover, if you have several different SQLite database files, each of them carries schema information. So when for later releases or versions of your software you need to have schema changes, make sure you do not have to change each SQLite file manually, one-by-one. Another factor is version control: binary files are not well suited for diff/merge tools, SQL scripts or textual code work much better with this. So even if you decide to distribute the binary SQLite files for the settings directly to your end user, and to not embed the creational code directly into your app, you should at least have the such code in some kind of internal generator tool, which is kept in version control instead of the binary files.

The best, from a user perspective, is to check for the existence of a setting, and if it is not present create a default. (same applies to the DB: if its not present, create it)

This allows all settings to always be present in your DB, allow them all to be customised without worrying that you’re going to trash an alreayd0-customised setting, and give the user the ease of not having to worry about setting up settings files at installation time.

You also get to add new settings to an existing installation without worry.