Did you ever wonder how to open SQLite database on iOS simulator? If yes, then you probably googled “how to find a path to SQLite database on iOS”. I think you’ve probably seen the solution where you have to open “Activity Monitor”, find your app in processes, check “open files and processes” and search for “.sqlite”. Then copy the path and open it in “Db browser for SQLite”. Sounds familiar? If yes and you are fed up with this stick with me for the next 10minutes.
Disclaimer
This solution only works for Mac computers.
Shell script FTW
This week, I’ve decided that I have enough. Although the process of opening a database is not that hard, it’s easy to forget and pretty boring. When doing manual stuff, I try to think if there is a way to make it automatic. In this case, I’ve decided to try if I can write a bash script, to open the database for me.
Requirements
Let me quickly explain the requirements that you need to fulfil. You have to:
- Have installed “Db browser for SQLite” (or something that can open .sqlite file)
- Have an app using SQLite database
- Your database file should have “.sqlite” extension
- You have to have the app running on your simulator
- You need to know the name of the process the app created
As you may have noticed those requirements are the same, like the one you need to fulfil when proceeding with “manual way”. I’ve just translated those steps to a shell script that’s all. No rocket science needed.
I am not sure if I have to describe all points, so let elaborate more on the last one.
By the process name I mean:
- in Xcode development the name of the project, so whatever is before “.xcodeproj” is the name,
- in Xamarin the name of Xamarin.iOS project.
If you work in ReactNative, Flutter etc. you can find the “name” by following these steps:
- Open Activity Monitor,
- go to memory tab,
- find a process that has a familiar name to the app you are working on.
Action
Knowing the above, let’s move forward. Create an empty file in Visual Studio Code (or whatever you use) and save it in some handy place. Copy the following code to your file.
Now I will ask you to be creative. Find a name for your script and save it with “.sh” extension. We are almost done. Hold on one more minute.
Now you need to open a terminal 😬
I know that many developers don’t want to open a terminal as they think it’s reserved for hackers, DevOps etc. But trust me, it can be pretty helpful, so don’t be afraid.
In opened terminal navigate to the location where you have saved you “.sh” file.
Now, you need to run chmod +x your-file-name.sh
. You need to run it only once so fire and forget.
Now, check if your app is running on a simulator. If yes, proceed with running:
./your-file-name.sh YourAwesomeAppWithSQLiteName
Voilà! Db browser (or whatever you are using) should open.
Abstract
I’ve spent maybe 30minutes creating that shell script. I already know that it was worth it. Right now, opening the SQLite database takes me 10seconds instead of 2 minutes.
I really hope you will find this short blogpost helpfull. I’d really like to hear if you have any ideas on how to improve the script or the process of opening the database. You can leave me a comment or write to me via the contact form.
Thanks, that was helpful.
On my system the resulting path to the db file needs to be fixed as I might have several sqlite files associated with the Runner process and for some reason the path to the script itself is getting prepended to the path to the sqlite file ( btw: I call my sqlite files like so – myapp_database.sqlite ):
open_database() {
DB_PATH=
lsof -Fn -p $PID| grep "_database.sqlite$"
prefix=”/Volumes/myXternal/Dev/my_projects/n” # not sure why this path is getting prepended to the sqlite file location by lsof
DB_PATH=${DB_PATH#”$prefix”}
open ${DB_PATH:1}
}
Thanks Cory for your comment! Perfect that you found the problem and fixed your issue on your own. Hope that now you will be able to open the database quickly 😉
Thanks, for you script! Additionally I’ll recommend to take ${DB_PATH:1} in double quotes. In my case the path contains spaces and open command didn’t work properly.