Firstly, your schema should not be DEV. DEV is a user or role.
Your schema name should be related to the data content (eg ACCOUNTS or SALES)
Secondly, consider whether you or the customer is going to decide the schema name. Say you have a product called FLINTSTONE. You may decide that the schema name should be FLINTSTONE. However your customer may want to run two instances of your product (eg one for local sales, the other for international) and use the same database. So they want FS_LOCAL and FS_INTER as the schema names. Is that option a feature of your product ?
Next, decide if your application should connect as the schema owner. There are good security reasons for NOT doing that. For example, the schema owner has privileges to drop tables, which is generally something the application doesn't do and thus, on the principle of least privilege, is something your application shouldn't have privileges to do.
Generally I would recommend some config parameter for the application for the schema name, and after connecting to the database, the app should do an "ALTER SESSION SET CURRENT_SCHEMA = 'whatever was it the config file'". The application database user would need the appropriate insert/update/delete/select/execute privileges on the objects in the application schema. If the application can't do that, you can have a LOGON trigger in the database.