If you have exactly one app, and the server sends the JSON only to this app, you should go with @simon's advice. However, when you have a dozen apps, each of them needs a different part of the data, then tailoring the JSON to each of them (so making twelve different APIs, one for each app) might become cumbersome, inefficient and errorprone. If that's the situation, you will have to make a trade-off between network optimization and keeping the API maintainable.
For the latter case, two or three different reusable "views" to your business object may be a practical compromise. Moreover, if you use a generator to create the JSON and the model in your app from some meta model or data schema, then letting it generate some extra attributes you do not need immediately is not a violation of YAGNI. For a generator it does not make a big difference if it generates 10 attributes or 20 - it may be more effort the make the generator so flexible it can generate different APIs, and then it is questionable if that is more flexibility than you really need .
EDIT: There is another possible approach: each app could tell the server in some kind of query exactly which attributes it needs, and the server delivers that in a generic manner. A quick google search reveals there are already JSON query languages available for this scenario, see for example this former SO post or JSONiq.