I believe your topology suggests that you should go with manual identity management.
Since, you are trying to manage identity values manually, first & foremost you should be sure enough that your publisher and each of your subscribers use different identity ranges.
Let's say for e.g: consider a published table with an identity column defined as identity(1, 1), what will happen in this case is the identity column will start out at 1 and will keep on incrementing by 1 on every insert. So, if this table has on an average 5,000 rows, and you expect some further growth in the table over the life of the application, then it's possible this could use up the all the range from 1-10,000. Now if there are more than one subscribers, say for e.g 2 subscribers then subscriber "a" could use range from 10,001-20,000, and subscriber "b" could use a range from 20,001-30,000.
Now, what I mean to say here is, once your subscriber gets initialized either by means of a snapshot or backup (u r case), then execute dbcc checkident to assign a starting point for it's identity range. In the above example
it should be checkident('<tablename>', 'reseed', 10001) for subscriber a, and dbcc checkident('<tablename>', 'reseed', 20001) for subscriber b.
As per technet article, to assign new ranges to the publisher or subscribers, you should execute dbcc checkident and specify a new value to reseed the table.
I believe there should be some way in which your application could have a mechanism that detects when it is about to use up all of it's range, and then you could run dbcc checkident to provide new ranges. You can also add a check constraint on the identity column ensuring that a row cannot be added if it would cause an out of range identity value to be used.
I hope this helps.