Your question is very confused. I'll assume that English is not your first language and what you are really asking is "should a DBMS be exposed on the internet?"
he does not want the database password in the code
That's just the start of your problems.
There are things you can do to make the problem less bad than what you are currently proposing, but they still leave a lot to be desired.
Use the credentials provided by the user to authenticate in the DBMS
i.e. the database password is the user's password. This restricts the use of the database to known users (as opposed to making it available to anyone on the internet) and removes the need to embed the database password in the client. But it doesn't solve any of the other problems.
restrict the accounts access to only run stored procedures
Done properly, this would prevent an attacker from reading stuff from the database they shouldn't have access to - e.g. they should only be able to see their orders and not orders from other people. It also allows you to implement your business logic on the serverside (you can't trust logic implemented on the client). You should never store data which has not been vetted for compliance. This also gives some scope for managing the user experience more effectively when things do not proceed along the happy path. However its really hard to implement application logic in procedural SQL.
restrict the access to specific IP addresses
Where only known IP addresses will be accessing a service, this is good practice - it cuts down on the noise, but its not foolproof. And your mention of an IOS app (I presume you are referring to iOS, Apple's mobile device operating system, not IOS, which is Cisco's network device operating system) suggests you won't be able to determine the client address in advance.
...but these are not nearly enough protection!!!
DBMSs are simply not designed to be exposed in a potentially hostile environment. And SQL, using the same channel for data and control, is particularly susceptible to abuse. Nobody has been able to fix these problems on a DBMS - and indeed, nobody is trying any more as the solution is to implement a proper control layer, serverside, on top of the DBMS.