This is somewhat fragile, I believe. Normal best practice recommendation is to treat updated_seq as opaque and not rely on it having a particular structure. So you run the (probably small) risk of having this break on future updates.
There are at least a couple other approaches to doing this that will depend on specifics. If you can do backend processing, one way would be to keep a document with the IDs of the most recent updates. Pull that document first, then do a oneshot replication filtered by those document IDs. That could have problems with race conditions, so it would depend on how sensitive you are to that.
I believe there’s a solution in use by at least one other product that bins documents into channels by creation date. So, say, all of October 2017 goes into one channel.
One other idea (which I’ve never tried) would be to have a date stamp, or even a simple “new” vs. “old” flag. Assign documents to two channels based on the stamp/flag. This again I think would need a back end process to flip the flag, or in some other way trigger a reprocessing of the documents. You can just trigger a reprocessing of all documents, but that generally means having sync gateway effectively offline for a period.
You mean “pull from Sync Gateway”, correct? So this is referring to the first launch of the app.
Currently I am facing the issue like UI is busy for updating for certain time
There’s no need to block the UI while the replicator runs. You can display the current data and re-run your queries periodically when you get notified that the database has changed (by monitoring the changes feed.)